automotive wiki automotivewiki https://automotive.wiki/index.php/Hauptseite MediaWiki 1.27.3 first-letter Medium Spezial Diskussion Benutzer Benutzer Diskussion Automotive wiki Automotive wiki Diskussion Datei Datei Diskussion MediaWiki MediaWiki Diskussion Vorlage Vorlage Diskussion Hilfe Hilfe Diskussion Kategorie Kategorie Diskussion Blog Blog talk Gadget Gadget Diskussion Gadget-Definition Gadget-Definition Diskussion 0 1 1 2013-08-07T21:16:37Z MediaWiki default 0 wikitext text/x-wiki '''MediaWiki has been successfully installed.''' Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. == Getting started == * [//www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [//www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] b7a3846f2c55072191227d89a3204fe379288fee 0 4 5 2013-10-11T22:27:04Z Oliver 1 Created page with "A “Basic Storage Object” is the smallest entity of a “[[NVRAM block]]”. Several “Basic Storage Objects” can be used to build a [[NVRAM Block]]. A “Basic Storage ..." wikitext text/x-wiki A “Basic Storage Object” is the smallest entity of a “[[NVRAM block]]”. Several “Basic Storage Objects” can be used to build a [[NVRAM Block]]. A “Basic Storage Object“ can reside in different memory locations ([[RAM]]/[[ROM]]/[[NV memory]]). a50e57cb682b01135f39d66eed4f226588fa0a16 6 5 2013-10-11T22:27:54Z Oliver 1 wikitext text/x-wiki A “Basic Storage Object” is the smallest entity of a “[[NVRAM Block]]”. Several “Basic Storage Objects” can be used to build a [[NVRAM Block]]. A “Basic Storage Object“ can reside in different memory locations ([[RAM]]/[[ROM]]/[[NV memory]]). 0d24df477829d6da5d73dbf309e48e5eae8a920a 0 2 2 2013-10-11T22:29:24Z Oliver 1 Created page with "The “NVRAM Block” is the entire structure, which is needed to administrate and to store a block of [[NV]] data." wikitext text/x-wiki The “NVRAM Block” is the entire structure, which is needed to administrate and to store a block of [[NV]] data. a6f78a2ee106045eb6347a9448ab7ddf6bda1df0 3 2 2013-10-11T22:29:48Z Oliver 1 wikitext text/x-wiki The “NVRAM Block” is the entire structure, which is needed to administrate and to store a block of [[NV data]]. b0e9a749b3b7bf06178a3e6a8b1c3962f32bf93b 0 5 7 2013-10-11T22:29:48Z Oliver 1 Created page with "Type of the [[NVRAM Block]]. It depends on the (configurable) individual [[composition]] of a [[NVRAM Block]] in chunks of different mandatory/optional [[Basic Storage Object]..." wikitext text/x-wiki Type of the [[NVRAM Block]]. It depends on the (configurable) individual [[composition]] of a [[NVRAM Block]] in chunks of different mandatory/optional [[Basic Storage Object]]s and the subsequent handling of this [[NVRAM Block]]. be5e57d0b3fb4745541f63c480d853b34974cfa6 0 3 4 2013-10-11T22:30:10Z Oliver 1 Created page with "The data to be stored in [[Non-Volatile memory]]." wikitext text/x-wiki The data to be stored in [[Non-Volatile memory]]. d8653bc494965b6c59b78b4abe524d72dc3bbf1d 0 6 8 2013-10-11T22:30:52Z Oliver 1 Created page with "The „RAM Block“ is a [[Basic Storage Object]]. It represents the part of a [[NVRAM Block]] which resides in the [[RAM]]." wikitext text/x-wiki The „RAM Block“ is a [[Basic Storage Object]]. It represents the part of a [[NVRAM Block]] which resides in the [[RAM]]. 53ad2fcff6f5bed6baef6a93468b820ae309e770 0 7 9 2013-10-11T22:33:02Z Oliver 1 Created page with "The „ROM Block“ is a [[Basic Storage Object]]. It represents the part of a [[NVRAM Block]] which resides in the [[ROM]]. The „ROM Block“ is an optional part of a [[NVR..." wikitext text/x-wiki The „ROM Block“ is a [[Basic Storage Object]]. It represents the part of a [[NVRAM Block]] which resides in the [[ROM]]. The „ROM Block“ is an optional part of a [[NVRAM Block]]. 9ea45b3f41f4c2e91e773a28a977540771a03f85 0 8 10 2013-10-11T22:34:01Z Oliver 1 Created page with "The „NV Block“ is a [[Basic Storage Object]]. It represents the part of a [[NVRAM Block]] which resides in the [[NV memory]]. The „NV Block“ is a mandatory part of a [..." wikitext text/x-wiki The „NV Block“ is a [[Basic Storage Object]]. It represents the part of a [[NVRAM Block]] which resides in the [[NV memory]]. The „NV Block“ is a mandatory part of a [[NVRAM Block]]. a37643b2cccfe1758db253b0ea0f97b00200ec42 0 9 11 2013-10-11T22:34:45Z Oliver 1 Created page with "Additional information included in the [[NV Block]] if the mechanism “[[Static Block ID]]” is enabled." wikitext text/x-wiki Additional information included in the [[NV Block]] if the mechanism “[[Static Block ID]]” is enabled. d7c329f286ea874d6af93fd91cbf36be4b828344 0 10 12 2013-10-11T22:35:28Z Oliver 1 Created page with "The “Administrative Block” is a [[Basic Storage Object]]. It resides in [[RAM]]. The “Administrative Block” is a mandatory part of a [[NVRAM Block]]." wikitext text/x-wiki The “Administrative Block” is a [[Basic Storage Object]]. It resides in [[RAM]]. The “Administrative Block” is a mandatory part of a [[NVRAM Block]]. af838ab05c32440306189ee918b80d0d0381a2d6 0 11 13 2013-10-11T22:36:08Z Oliver 1 Created page with "Development Error Tracer module to which development errors are reported." wikitext text/x-wiki Development Error Tracer module to which development errors are reported. ae1192bd1a8fd90996d071d20c5a389d0f2f1d07 0 12 14 2013-10-11T22:36:46Z Oliver 1 Created page with "Diagnostic Event Manager module to which production relevant errors are reported." wikitext text/x-wiki Diagnostic Event Manager module to which production relevant errors are reported. 407cfee907e51468bde06fe1ca3d497798c4e6d0 0 13 15 2013-10-11T22:37:17Z Oliver 1 Created page with "Non volatile." wikitext text/x-wiki Non volatile. c7b68890ae7196a27599711db90df92d03f71f2a 0 14 16 2013-10-11T22:37:45Z Oliver 1 Created page with "[[Flash]] [[EEPROM]] Emulation." wikitext text/x-wiki [[Flash]] [[EEPROM]] Emulation. a4d96a1193381dcff6b2fcded3c0660cfa589130 0 15 17 2013-10-11T22:38:10Z Oliver 1 Created page with "[[EEPROM]] Abstraction." wikitext text/x-wiki [[EEPROM]] Abstraction. 4ef7b26a237acc1f84cb896f6c5f94702e16dedf 0 16 18 2013-10-11T22:38:35Z Oliver 1 Created page with "First come first served." wikitext text/x-wiki First come first served. 9a62e4417628d30462b589ac0dcc73d450421831 0 17 19 2013-10-11T22:43:02Z Oliver 1 Created page with "NvM module is provided with a virtual linear 32bit address space which is composed of a 16bit [[logical block number]] and a 16bit [[block address offset]]. ..." wikitext text/x-wiki NvM module is provided with a virtual linear 32bit address space which is composed of a 16bit [[logical block number]] and a 16bit [[block address offset]]. ... 07b08bc81398441f003bf5e3796aaf03b0a06a02 0 18 20 2013-10-20T20:45:21Z Oliver 1 Created page with "Non volatile Memory" wikitext text/x-wiki Non volatile Memory 73cbd3dae25b3a1db5c06335394ff496ca7ec32b 0 19 21 2013-12-17T21:20:26Z Oliver 1 Created page with "Analog Digital Converter" wikitext text/x-wiki Analog Digital Converter 0a626ee3cbdfd5e74e3be64e499938d151e73732 0 20 22 2013-12-17T21:20:47Z Oliver 1 Created page with "Application Mode Management" wikitext text/x-wiki Application Mode Management c02286cbbc9d2ec44bdb3a5221e51f6293ea4263 0 21 23 2013-12-17T21:21:08Z Oliver 1 Created page with "Application Programming Interface" wikitext text/x-wiki Application Programming Interface a63f73a380e6bb14bdd2ad6b10a8f68e5d42a5ad 0 22 24 2013-12-17T21:21:22Z Oliver 1 Created page with "Address Resolution Protocol" wikitext text/x-wiki Address Resolution Protocol f6d99af3a38c625454657d0ea838ce2c256ab431 0 23 25 2013-12-17T21:22:39Z Oliver 1 Created page with "Association for Standardization of Automation and Measuring systems [http://www.asam.net]" wikitext text/x-wiki Association for Standardization of Automation and Measuring systems [http://www.asam.net] 5f877b9e6c878b57670141160fe50e769cefbef6 0 24 26 2013-12-17T21:22:56Z Oliver 1 Created page with "Automotive Safety Integrity Levels" wikitext text/x-wiki Automotive Safety Integrity Levels febcc95c7c8aa006a8bf083bba09318810add8fd 0 25 27 2013-12-17T21:23:33Z Oliver 1 Created page with "AUTomotive Open System Architecture [http://www.autosar.org]" wikitext text/x-wiki AUTomotive Open System Architecture [http://www.autosar.org] 04266b6ebd40a2cacf7e697ff1bcfa75133faf72 0 26 28 2013-12-17T21:23:47Z Oliver 1 Created page with "Basic SoftWare" wikitext text/x-wiki Basic SoftWare d3d03683b9ca70d2aeac8fed891c95339deaf579 30 28 2013-12-17T21:27:24Z Oliver 1 wikitext text/x-wiki [[Basic SoftWare]] ec11ebf42172f679ccc32e08d0de0c708af0cdff 0 27 29 2013-12-17T21:27:10Z Oliver 1 Created page with "[[Basic SoftWare]] Module" wikitext text/x-wiki [[Basic SoftWare]] Module dbf6a926975c69733bea4bc9e1c127e738b53d0a 0 28 31 2013-12-17T21:28:03Z Oliver 1 Created page with "Controller Area Network" wikitext text/x-wiki Controller Area Network 9bc32c82fdd4396bb5b78705d715e113f0113651 0 29 32 2013-12-17T21:28:28Z Oliver 1 Created page with "Complex Driver" wikitext text/x-wiki Complex Driver a72a273721f348cea6e82a222012ac1564ff9081 0 30 33 2013-12-17T21:28:40Z Oliver 1 Created page with "Complex Device Driver" wikitext text/x-wiki Complex Device Driver 13cebe193bc6819ec4fac6095724b4f15f7bef28 0 31 34 2013-12-17T21:28:53Z Oliver 1 Created page with "Communication" wikitext text/x-wiki Communication ade0d50c9254cf0c9459bbfe2398553c1fee3ecb 0 32 35 2013-12-17T21:29:09Z Oliver 1 Created page with "Central Processing Unit" wikitext text/x-wiki Central Processing Unit e291d4caf94c0fd37a904e6f629e4bceab44c871 0 33 36 2013-12-17T21:29:22Z Oliver 1 Created page with "Conformance Test Agency" wikitext text/x-wiki Conformance Test Agency 3934d2014d40d79c8de6c31f280aa7c85e55fbfa 0 34 37 2013-12-17T21:29:36Z Oliver 1 Created page with "Conformance Test Suite" wikitext text/x-wiki Conformance Test Suite f68eda536972c314311f7a3021ed28744d85464f 0 35 38 2013-12-17T21:29:48Z Oliver 1 Created page with "Digital to Analog Converter" wikitext text/x-wiki Digital to Analog Converter 81e0c88c2827fd666cb2ae390c2ffd5bc1ca8cc9 0 36 39 2013-12-17T21:30:25Z Oliver 1 Created page with "Dynamic Host Configuration Protocol" wikitext text/x-wiki Dynamic Host Configuration Protocol df5d67316d71d0ff79b767ad1a7c12b45c476d44 0 37 40 2013-12-17T21:30:39Z Oliver 1 Created page with "Digital Input/Output" wikitext text/x-wiki Digital Input/Output 71c3697160c8a2980e16bddb5a8f0087449b86c3 0 38 41 2013-12-17T21:30:51Z Oliver 1 Created page with "Data Length Code" wikitext text/x-wiki Data Length Code 7cf40266b053ba1f7f7049b518b59fc531951a9a 0 39 42 2013-12-17T21:31:08Z Oliver 1 Created page with "Diagnostics over Internet Protocol" wikitext text/x-wiki Diagnostics over Internet Protocol acd61a3a4f6a02c94753d856f4518e31b39bab33 0 40 43 2013-12-17T21:31:23Z Oliver 1 Created page with "Document Type Definition" wikitext text/x-wiki Document Type Definition fc145c111fa5f77b3127903a1672cc3fc22159c0 0 41 44 2013-12-17T21:31:38Z Oliver 1 Created page with "Electronic Control Unit" wikitext text/x-wiki Electronic Control Unit aae0aadee9aa43d57b18349dcf3ab9fedd055e65 0 42 45 2013-12-17T21:51:17Z Oliver 1 Created page with "First In First Out" wikitext text/x-wiki First In First Out 275e9ad910c6ee6a62f319ef827003041f3e5993 0 43 46 2013-12-17T21:51:30Z Oliver 1 Created page with "Floating Point Unit" wikitext text/x-wiki Floating Point Unit d2a2637ccd42c8b88a6d84ecb067f7023134d2fb 0 44 47 2013-12-17T21:51:42Z Oliver 1 Created page with "Fire Wire" wikitext text/x-wiki Fire Wire e1436c8cc5d9ad8123f493ce060c1205fffec9c5 0 45 48 2013-12-17T21:51:55Z Oliver 1 Created page with "Global System for Mobile Communication" wikitext text/x-wiki Global System for Mobile Communication 2f2eb90a3d606dd0f3378d628fec834a4250b124 0 46 49 2013-12-17T21:52:30Z Oliver 1 Created page with "Hersteller Initiative Software [http://www.automotive-his.de]" wikitext text/x-wiki Hersteller Initiative Software [http://www.automotive-his.de] 9561931e9b22878e8baffd50f6ba349ea2503d35 0 47 50 2013-12-17T21:52:45Z Oliver 1 Created page with "Hardware" wikitext text/x-wiki Hardware b76ab65957a69ff57e8c72352794d437fd34c788 0 48 51 2013-12-17T21:52:59Z Oliver 1 Created page with "Implementation Conformance Class" wikitext text/x-wiki Implementation Conformance Class 5ba03b194007f4f8315ca8ba32cf522ba808a5e1 0 49 52 2013-12-17T21:53:16Z Oliver 1 Created page with "Internet Control Message Protocol" wikitext text/x-wiki Internet Control Message Protocol 1c9eb8fe39b663da62bd55d532bbc1d6dc4480d5 0 50 53 2013-12-17T21:53:31Z Oliver 1 Created page with "International Electrotechnical Commission" wikitext text/x-wiki International Electrotechnical Commission 9a4222dfc9fdc77f19f92dba6e20438075629f39 0 51 54 2013-12-17T21:53:56Z Oliver 1 Created page with "Interaction Layer Protocol Data Unit ([[PDU]])" wikitext text/x-wiki Interaction Layer Protocol Data Unit ([[PDU]]) a10c32361027ee147d3f8da7e9cc55d2ac7281e9 0 52 55 2013-12-17T21:54:11Z Oliver 1 Created page with "Interrupt Service Routine" wikitext text/x-wiki Interrupt Service Routine a9448404e4abbec1842d19564d29574a6bd766d6 0 53 56 2013-12-17T21:54:47Z Oliver 1 Created page with "Protocol Data Unit ([[PDU]]) of the data link layer" wikitext text/x-wiki Protocol Data Unit ([[PDU]]) of the data link layer f55afb29be96b41a4783ec577aaff0f2bd19ac4c 0 54 57 2013-12-17T21:55:35Z Oliver 1 Created page with "Service Data Unit [[SDU]] of the data link layer" wikitext text/x-wiki Service Data Unit [[SDU]] of the data link layer 5bd1a4969a0bd4adf6992c2f98aa942145732883 0 55 58 2013-12-17T21:55:51Z Oliver 1 Created page with "Last In First Out" wikitext text/x-wiki Last In First Out f9521b7b2d32875e18ecc5450e48b0e45b5561a4 0 56 59 2013-12-17T21:56:03Z Oliver 1 Created page with "Local Interconnected Network" wikitext text/x-wiki Local Interconnected Network cce5d34e41308f1a568877eeb2cd6b74bbddbee4 0 57 60 2013-12-17T21:56:20Z Oliver 1 Created page with "Least Significant Bit/Byte" wikitext text/x-wiki Least Significant Bit/Byte 6de323f75fc3f333e02dc316a19cc2c976b2fdef 0 58 61 2013-12-17T21:56:35Z Oliver 1 Created page with "MicroController" wikitext text/x-wiki MicroController bd4d8fb44eefd2999112d16a0c9b67c8f9383a46 0 59 62 2013-12-17T21:56:53Z Oliver 1 Created page with "Micro Controller Abstraction Layer" wikitext text/x-wiki Micro Controller Abstraction Layer 1bc59cb79119e1140d68e6d9776ff539e44b8482 0 60 63 2013-12-17T22:07:26Z Oliver 1 Created page with "Million Instructions Per Second" wikitext text/x-wiki Million Instructions Per Second 90f2a4996cfb865080da62b25cf3aaefb136c1ae 0 61 64 2013-12-17T22:07:40Z Oliver 1 Created page with "Memory Management Unit" wikitext text/x-wiki Memory Management Unit c57abbf7350f8f23facfe2096681f34a2aeeb91e 0 62 65 2013-12-17T22:07:55Z Oliver 1 Created page with "Man Machine Interface" wikitext text/x-wiki Man Machine Interface a684ba1dbeb533e3068b5c4e21d9c24369eb68f6 0 63 66 2013-12-17T22:08:09Z Oliver 1 Created page with "Human Machine Interface" wikitext text/x-wiki Human Machine Interface 92f178b31c5b182ef2c58460e3c90b1f9d9e3a39 0 64 67 2013-12-17T22:08:22Z Oliver 1 Created page with "Media Oriented Systems Transport" wikitext text/x-wiki Media Oriented Systems Transport c14e3b18d90541496cc493696a338b7b4ad024ad 0 65 68 2013-12-17T22:08:56Z Oliver 1 Created page with "Memory Protection Unit" wikitext text/x-wiki Memory Protection Unit bfc73bcbd25b988af2a34dab4581c3787250c98d 0 66 69 2013-12-17T22:09:10Z Oliver 1 Created page with "Most Significant Bit/Byte" wikitext text/x-wiki Most Significant Bit/Byte 2b9fcbc549080a6a607a549b98202c7e2e14abaa 0 67 70 2013-12-17T22:10:02Z Oliver 1 Created page with "Protocol Data Unit ([[PDU]]) of the network layer (transport protocols)" wikitext text/x-wiki Protocol Data Unit ([[PDU]]) of the network layer (transport protocols) d35ed5cbb13b765787f9b3d7ac67ce02365d0580 0 68 71 2013-12-17T22:10:43Z Oliver 1 Created page with "Service Data Unit ([[SDU]]) of the Network layer (transport protocols)" wikitext text/x-wiki Service Data Unit ([[SDU]]) of the Network layer (transport protocols) f07f0efe47f499c7ae08079e10f1bc0deb31784e 0 69 72 2013-12-17T22:10:58Z Oliver 1 Created page with "Service Data Unit" wikitext text/x-wiki Service Data Unit 989520f535ef8b9ed313f212f9b948f043fb28ec 0 70 73 2013-12-17T22:11:16Z Oliver 1 Created page with "Protocol Data Unit" wikitext text/x-wiki Protocol Data Unit 17863ca246067980dd077969f647a520921bbdc1 0 71 74 2013-12-17T22:11:41Z Oliver 1 Created page with "Non-Volatile Random Access Memory ([[RAM]])" wikitext text/x-wiki Non-Volatile Random Access Memory ([[RAM]]) da0e8450e51d21b6c84258c3793580219343cb1b 0 72 75 2013-12-17T22:11:51Z Oliver 1 Created page with "Random Access Memory" wikitext text/x-wiki Random Access Memory 0bbeec96b3d2096d365b8e98a435831cb96d0583 0 73 76 2013-12-17T22:12:17Z Oliver 1 Created page with "Original Equipment Manufacturer, resp. vehicle manufacturer" wikitext text/x-wiki Original Equipment Manufacturer, resp. vehicle manufacturer 1d7d01cc82afc2b2993b35daa6921e5910dad50c 0 74 77 2013-12-17T22:12:42Z Oliver 1 Created page with "[[OSEK]] Implementation Language" wikitext text/x-wiki [[OSEK]] Implementation Language 91c1aae06668cef1e80edbf6a9d5345f07f60ef5 0 75 78 2013-12-17T22:12:54Z Oliver 1 Created page with "Open Systems and the Corresponding Interfaces for Automotive Electronics" wikitext text/x-wiki Open Systems and the Corresponding Interfaces for Automotive Electronics 979f34a3531435d78482713ad6d2bd3d2a4c7722 0 76 79 2013-12-17T22:13:12Z Oliver 1 Created page with "Operating System" wikitext text/x-wiki Operating System e5ba86326755952233b0543acced2995e5faf457 0 77 80 2013-12-17T22:13:25Z Oliver 1 Created page with "Protocol Control Information" wikitext text/x-wiki Protocol Control Information ffd6d7b2309700d215cf05b5edfc80e5484f25cc 0 78 81 2013-12-17T22:13:45Z Oliver 1 Created page with "Product Supplier" wikitext text/x-wiki Product Supplier 4d529cb5a83767ee71100e7ba0c79fbacc2349ca 0 79 82 2013-12-17T22:14:01Z Oliver 1 Created page with "Pulse Width Modulation" wikitext text/x-wiki Pulse Width Modulation 2c569d3738ad38cc99ca47a42978f744abf44df8 0 80 83 2013-12-17T22:14:22Z Oliver 1 Created page with "Request for Change" wikitext text/x-wiki Request for Change ca84711e797de8382d505fd3a5fa26d14563e0b3 0 81 84 2013-12-17T22:14:36Z Oliver 1 Created page with "Request for quotation" wikitext text/x-wiki Request for quotation 10a8cd958dd6c18abb8248d444396b47de6eba04 0 82 85 2013-12-17T22:15:01Z Oliver 1 Created page with "Runtime Environment" wikitext text/x-wiki Runtime Environment c844e6393ee206daccee2de493daef42be7a6698 0 83 86 2013-12-17T22:15:59Z Oliver 1 Created page with "Society of Automotive Engineers [http://www.sae.org]" wikitext text/x-wiki Society of Automotive Engineers [http://www.sae.org] 972669d85dd53a160c905e9fa1a8bd03af84a24d 0 84 87 2013-12-17T22:16:20Z Oliver 1 Created page with "Safety Integrity Level" wikitext text/x-wiki Safety Integrity Level 1dbaff2ae55b3317a1f514f6e838ff3b186a4a50 0 85 88 2013-12-17T22:16:36Z Oliver 1 Created page with "Software" wikitext text/x-wiki Software 9ad052271e0186ed108ab51a2c5684a90c5a025a 0 86 89 2013-12-17T22:16:48Z Oliver 1 Created page with "Software Component" wikitext text/x-wiki Software Component 89641231b6809e4ab1bb2ef6428983c65729802a 0 87 90 2013-12-17T22:17:15Z Oliver 1 Created page with "[[SW-C]]" wikitext text/x-wiki [[SW-C]] f0b4f50912f2e2d4272c047511cbf20030887115 0 88 91 2013-12-17T22:18:05Z Oliver 1 Created page with "Transmission Control Protocol" wikitext text/x-wiki Transmission Control Protocol a4f515edfc4806822304c5e5ba93f1584400280b 0 89 92 2013-12-17T22:19:30Z Oliver 1 Created page with "Transport Protocol" wikitext text/x-wiki Transport Protocol 6d4ed04955b99e2e25f46f14a243ff2be9d1edb1 0 90 93 2013-12-17T22:19:42Z Oliver 1 Created page with "Time Triggered Protocol" wikitext text/x-wiki Time Triggered Protocol 131778e9e3d63e906e8274b709b5ea2ac5220e5a 0 91 94 2013-12-17T22:19:57Z Oliver 1 Created page with "User (Universal) Datagram Protocol" wikitext text/x-wiki User (Universal) Datagram Protocol 96e9d53044fd96d1085bec4199713f8fe611a0e8 0 92 95 2013-12-17T22:20:19Z Oliver 1 Created page with "[[UDP]] Network Management" wikitext text/x-wiki [[UDP]] Network Management c1d0001c15dbd453ccf16e8869f9dcd443556bbe 0 93 96 2013-12-17T22:20:30Z Oliver 1 Created page with "Universal Serial Bus" wikitext text/x-wiki Universal Serial Bus 37b79c7be8e44f7960e9b0b3e938261f8933d210 0 94 97 2013-12-17T22:20:51Z Oliver 1 Created page with "Virtual Functional Bus" wikitext text/x-wiki Virtual Functional Bus 3e74d2ddaa969a02d5c4d46894f4bab397c9ef47 0 95 98 2013-12-17T22:21:06Z Oliver 1 Created page with "Vehicle Mode Management" wikitext text/x-wiki Vehicle Mode Management 8c7d5486e53283d958afced4c5d08e3ea26377eb 0 96 99 2013-12-17T22:21:20Z Oliver 1 Created page with "Worst Case Execution Time" wikitext text/x-wiki Worst Case Execution Time d7174b3ac96d297e48eb701d781719a003973303 0 97 100 2013-12-17T22:21:34Z Oliver 1 Created page with "Worst Case Response time" wikitext text/x-wiki Worst Case Response time 814fc2b2ebd728c69e6acf968dc92612dc8bd935 0 98 101 2013-12-17T22:21:48Z Oliver 1 Created page with "Universal Calibration Protocol" wikitext text/x-wiki Universal Calibration Protocol 1726f4e7f9d1cc2e285d60ead333c1d6065bc98c 0 99 102 2013-12-17T22:22:01Z Oliver 1 Created page with "[[CAN]] Calibration Protocol" wikitext text/x-wiki [[CAN]] Calibration Protocol 1d425fbf6c444ec41557b3cffb8b842473b39d23 0 100 103 2013-12-17T22:22:14Z Oliver 1 Created page with "Extensible Markup Language" wikitext text/x-wiki Extensible Markup Language d8379449b77cd40626b7ba635ee49b685b2d0526 0 101 104 2013-12-17T22:24:27Z Oliver 1 Created page with "[[Third-party]] attestation to an organization conveying formal demonstration of its competence to carry out AUTOSAR conformance test tasks. Within the AUTOSAR environment tw..." wikitext text/x-wiki [[Third-party]] attestation to an organization conveying formal demonstration of its competence to carry out AUTOSAR conformance test tasks. Within the AUTOSAR environment two different scopes of accreditation exist: - In reference to ISO/IEC 17025 for accreditation of organizations performing conformance testing within own laboratories. - In reference to ISO/IEC Guide 65 for accreditation of [[Conformance Test Agencies]] ([[CTA]]) performing 3rd party product conformance attestation. 867adf77a5231927b7b78d9fc51c4f64ba878384 0 102 105 2013-12-17T22:25:21Z Oliver 1 Created page with "This is an organization, which employs or contracts individual [[assessor]]s, who in turn perform the [[independent assessment]]s as part of the [[accreditation]] process." wikitext text/x-wiki This is an organization, which employs or contracts individual [[assessor]]s, who in turn perform the [[independent assessment]]s as part of the [[accreditation]] process. 279e43f699989713226f3eb1aafd354c47f4361e 106 105 2013-12-17T22:26:03Z Oliver 1 wikitext text/x-wiki This is an organization, which employs or contracts individual [[assessor]]s, who in turn perform the [[independent assessment]]s as part of the [[accreditation]] process. In the AUTOSAR context the Accreditation Bodies have the role to accredit the [[Conformance Test Agencies]]. 3b766e86ef0d8895972cb5da18fdc7b9fa7f851f 0 110 115 2013-12-17T22:27:35Z Oliver 1 Created page with "Issue of a statement, based on a decision following a [[review]], that fulfillment of specified requirements has been demonstrated. The resulting statement, referred to in the..." wikitext text/x-wiki Issue of a statement, based on a decision following a [[review]], that fulfillment of specified requirements has been demonstrated. The resulting statement, referred to in the International Standard as a "statement of conformity", conveys the assurance that the specified requirements have been fulfilled. Such an assurance does not, of itself, afford contractual or other legal guarantees. Attestation of product conformance given by a third party like a [[CTA]]. Attestation of product conformance given by a first party like the Product Supplier (also called declaration). 400bd46a04cec4f45fc6a7f08036b9c389389347 0 103 107 2013-12-17T22:27:59Z Oliver 1 Created page with "1. A software (or program) that is specified to the solution of a problem of an end user requiring information processing for its solution. In AUTOSAR Application software is ..." wikitext text/x-wiki 1. A software (or program) that is specified to the solution of a problem of an end user requiring information processing for its solution. In AUTOSAR Application software is located above the AUTOSAR [[RTE]]. 2. The [[software configuration]] of a [[software entity]]. Definition 1 is the “by default” meaning for application in AUTOSAR. When definition 2 is meant, it has to be explicitly mentioned. 5048672e6ecad1ca047489a4ad67b8e85cba5012 0 111 116 2013-12-17T22:28:44Z Oliver 1 Created page with "Non-composed Software-Component ([[SW-C]]). An Atomic Software Component might access [[HW]] or not, therefore not all Atomic SW-Cs are re-locatable." wikitext text/x-wiki Non-composed Software-Component ([[SW-C]]). An Atomic Software Component might access [[HW]] or not, therefore not all Atomic SW-Cs are re-locatable. 12d5d0067b47d3ca711d867d265a8f2f5679b98b 0 21 108 23 2013-12-17T22:29:31Z Oliver 1 wikitext text/x-wiki An Application Programming Interface (API) is the prescribed method of a specific software part by which a programmer writing a program can make requests to that software part. It precisely defines the interfaces with all it's parameters. 659f784707b6def757c9b0f9eb8b471331256972 0 24 117 26 2013-12-17T22:29:38Z Oliver 1 wikitext text/x-wiki Automotive Safety Integrity Levels (ASIL) are used within [[ISO 26262]] to express the level of risk reduction required to prevent a specific hazard, with ASIL D representing the highest and ASIL A the lowest. The ASIL is assigned to the according safety goal and inherited to the safety requirements derived from it. 91e31608cf24225e3bcd9e2464cdeb907fdfcf86 0 104 109 2013-12-17T22:30:33Z Oliver 1 Created page with "An Application Software Component is a specific [[Software Component]] which realizes a defined functionality on application level (above the [[RTE]]) and runs on the AUTOSAR ..." wikitext text/x-wiki An Application Software Component is a specific [[Software Component]] which realizes a defined functionality on application level (above the [[RTE]]) and runs on the AUTOSAR infrastructure. It communicates only through the AUTOSAR Runtime Environment (RTE). a2d502e5e6284eed69f330046a1d859936baa815 0 105 110 2013-12-17T22:31:06Z Oliver 1 Created page with "The fundamental organization of a system embodied in its components, their static and dynamic relationships to each other, and to the environment, and the principles guiding i..." wikitext text/x-wiki The fundamental organization of a system embodied in its components, their static and dynamic relationships to each other, and to the environment, and the principles guiding its design and evolution. 82fe58d478fb7540cf2c55570a0d71c4e93743dc 0 112 118 2013-12-17T22:31:22Z Oliver 1 Created page with "The AUTOSAR Interface of a software component ([[SW-C]]) refers to the collection of all [[ports]] of that [[component]] through which it interacts with other components." wikitext text/x-wiki The AUTOSAR Interface of a software component ([[SW-C]]) refers to the collection of all [[ports]] of that [[component]] through which it interacts with other components. 85c26917ef2b1bc72b5bc8beaccddec642b23a76 0 106 111 2013-12-17T22:31:42Z Oliver 1 Created page with "This is a [[Work Product]] Definition that provides a description and definition for tangible work product types. Artifacts may be composed of other artifacts. At a high level..." wikitext text/x-wiki This is a [[Work Product]] Definition that provides a description and definition for tangible work product types. Artifacts may be composed of other artifacts. At a high level, an artifact is represented as a single conceptual file. cb0f2fcaa8c1e33a3a3f976ae1425d7d6370232a 0 113 119 2013-12-17T22:33:22Z Oliver 1 Created page with "The AUTOSAR metamodel is a [[UML]]2.0 model that defines the language for describing [[AUTOSAR system]]s and related [[artifact]]s. It is a graphical representation of a [[te..." wikitext text/x-wiki The AUTOSAR metamodel is a [[UML]]2.0 model that defines the language for describing [[AUTOSAR system]]s and related [[artifact]]s. It is a graphical representation of a [[template]]. UML2.0 class diagrams are used to describe the [[attribute]]s and their [[interrelationship]]s. [[Stereotype]]s and [[OCL]] (object constraint language) are used for defining specific [[semantic]]s and constraints. 4d32b51ab5aacc2d0bd13fbfd26f5f664a24648f 0 107 112 2013-12-17T22:34:24Z Oliver 1 Created page with "Activity conducted by an [[assessor]] to demonstrate that the assessed organization fulfills the set requirements. Within the AUTOSAR context after the initial assessment a ne..." wikitext text/x-wiki Activity conducted by an [[assessor]] to demonstrate that the assessed organization fulfills the set requirements. Within the AUTOSAR context after the initial assessment a new full-set assessment will be repeated every 4 years. In between, [[surveillances]] take place once a year. bae46ba6c3002440b2463f3b60ec4fe2792d826f 0 114 120 2013-12-17T22:34:35Z Oliver 1 Created page with "This is a representation of an [[AUTOSAR product]]. The AUTOSAR model represents aspects suitable to the intended use according to the [[AUTOSAR methodology]]. Strictly speaki..." wikitext text/x-wiki This is a representation of an [[AUTOSAR product]]. The AUTOSAR model represents aspects suitable to the intended use according to the [[AUTOSAR methodology]]. Strictly speaking, this is an instance of the [[AUTOSAR metamodel]]. The information contained in the AUTOSAR model can be anything that is representable according to the AUTOSAR metamodel. 0bfe3362c4be33bc174f8730375105bf5d7cf098 0 108 113 2013-12-17T22:34:56Z Oliver 1 Created page with "An item that has been designed for use in multiple contexts. An asset can be design, specifications, source code, documentation, test suits, manual procedures, etc." wikitext text/x-wiki An item that has been designed for use in multiple contexts. An asset can be design, specifications, source code, documentation, test suits, manual procedures, etc. 0eaa3e4152c6a06571fcf7a89e8d9af507379da9 0 115 121 2013-12-17T22:35:41Z Oliver 1 Created page with "In AUTOSAR, the possible partitioning of models is marked in the meta-model by <<atpSplitable>>. One partial model is represented in an [[AUTOSAR XML description]] by one file..." wikitext text/x-wiki In AUTOSAR, the possible partitioning of models is marked in the meta-model by <<atpSplitable>>. One partial model is represented in an [[AUTOSAR XML description]] by one file. The partial model does not need to fulfill all semantic constraints applicable to an [[AUTOSAR model]]. bc193b60ac429d26824f1249762ada712b818bac 0 109 114 2013-12-17T22:35:57Z Oliver 1 Created page with "Asynchronous communication does not block the sending [[software entity]]. The sending software entity continues its operation without getting a response from the communicatio..." wikitext text/x-wiki Asynchronous communication does not block the sending [[software entity]]. The sending software entity continues its operation without getting a response from the communication partner(s). There could be an acknowledgement by the communication system about the sending of the information. A later response to the sending software entity is possible. b7a8597029ea8d3c033326ef871c6f70cc6ae715 0 116 122 2013-12-17T22:36:57Z Oliver 1 Created page with "An AUTOSAR Service is a logical [[entity]] of the basic software ([[BSW]]) offering general functionality to be used by various software components ([[SW-C]]). The functionali..." wikitext text/x-wiki An AUTOSAR Service is a logical [[entity]] of the basic software ([[BSW]]) offering general functionality to be used by various software components ([[SW-C]]). The functionality is accessed via standardized [[AUTOSAR Interface]]s. 3b0c40c379b8c0d308864794da13570050b556d5 123 122 2013-12-17T22:38:00Z Oliver 1 wikitext text/x-wiki An AUTOSAR Service is a logical [[entity]] of the basic software ([[BSW]]) offering general functionality to be used by various software components ([[SW-C]]). The functionality is accessed via standardized [[AUTOSAR Interface]]s. Parts of the basic software required to realize AUTOSAR communication patterns and communication attributes are not called AUTOSAR services. 60add64c707891240eecd89701764ef578737306 0 117 124 2013-12-17T22:38:45Z Oliver 1 Created page with "This is a software tool which supports one or more tasks defined as AUTOSAR tasks in the [[methodology]]. Depending on the supported tasks, an AUTOSAR tool can act as an [[aut..." wikitext text/x-wiki This is a software tool which supports one or more tasks defined as AUTOSAR tasks in the [[methodology]]. Depending on the supported tasks, an AUTOSAR tool can act as an [[authoring tool]], a [[converter tool]], a [[processor tool]] or as a combination of those. 172a4caef9ee9bc799100ecfd007879960940c8a 126 124 2013-12-17T22:40:53Z Oliver 1 wikitext text/x-wiki This is a software tool which supports one or more tasks defined as AUTOSAR tasks in the [[methodology]]. Depending on the supported tasks, an AUTOSAR tool can act as an [[AUTOSAR authoring tool]], a [[AUTOSAR converter tool]], a [[AUTOSAR processor tool]] or as a combination of those. 5b44a54af48aece95ed1ea632f248a4060b23337 0 118 125 2013-12-17T22:39:54Z Oliver 1 Created page with "In AUTOSAR this means "Filled Template". In fact an AUTOSAR XML description is the [[XML]] representation of an [[AUTOSAR model]]. The AUTOSAR XML description can consist of s..." wikitext text/x-wiki In AUTOSAR this means "Filled Template". In fact an AUTOSAR XML description is the [[XML]] representation of an [[AUTOSAR model]]. The AUTOSAR XML description can consist of several files. Each individual file represents an [[AUTOSAR partial model]] and must validate successfully against the [[AUTOSAR XML schema]]. a8473381d84ea95f5ba2c1f53c9600d263855d22 0 119 127 2013-12-17T22:42:08Z Oliver 1 Created page with "The AUTOSAR XML Schema is an [[XML]] language definition for exchanging [[AUTOSAR model]]s and descriptions. It is a W3C XML schema that defines the language for exchanging AU..." wikitext text/x-wiki The AUTOSAR XML Schema is an [[XML]] language definition for exchanging [[AUTOSAR model]]s and descriptions. It is a W3C XML schema that defines the language for exchanging AUTOSAR models. This Schema is derived from the [[AUTOSAR metamodel]]. The AUTOSAR XML Schema defines the AUTOSAR data exchange format. 06e27184fcb778ac3ed7e6b603e65070b751a926 0 120 128 2013-12-17T22:43:15Z Oliver 1 Created page with "1. Probability that a system or [[functional unit]] is able to perform its normal operation under specified conditions at a specific time. 2. The property of data or resources..." wikitext text/x-wiki 1. Probability that a system or [[functional unit]] is able to perform its normal operation under specified conditions at a specific time. 2. The property of data or resources being accessible and usable on demand by an authorized entity. The time can be used to model a decrease of the availability over time due to e.g. aging of [[component]]s. c52dc62456e2894a7111a1c5c9e88eb6dfb9eb3c 0 26 129 30 2013-12-17T22:44:12Z Oliver 1 wikitext text/x-wiki The Basic Software provides the infrastructural (schematic dependent and schematic independent) functionalities of an [[ECU]]. It consists of [[Integration Code]] and [[Standard Software]]. c6ae9e246b96aa389d6938c17fbb562f4c6eabe6 0 27 130 29 2013-12-17T22:45:10Z Oliver 1 wikitext text/x-wiki Basic Software ([[BSW]]) Module A collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. 41b649fe95be28474d9955e7a33ea4002987bc2c 131 130 2013-12-17T22:45:58Z Oliver 1 wikitext text/x-wiki Basic Software ([[BSW]]) Module A collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or [[standard software]]. a2ac26f12eb362770d9caab063cd4e4f1f225763 0 121 132 2013-12-17T22:47:16Z Oliver 1 Created page with "In AUTOSAR the bit position N within an [[I-PDU]] denotes the bit I, with I = N modulo 8, within the byte J, with J = N / 8. The byte J and bit position I is interpreted in ac..." wikitext text/x-wiki In AUTOSAR the bit position N within an [[I-PDU]] denotes the bit I, with I = N modulo 8, within the byte J, with J = N / 8. The byte J and bit position I is interpreted in accordance to the definition in [[OSEK]] [[COM]]: “An I-PDU is a sequence of bytes numbered from 0 upwards. Within an I-PDU byte, bits are numbered from 0 upwards with bit 0 being the least significant bit.” 6dd8479f247ca3c85b83d0882bd21c8579d9cef9 0 122 133 2013-12-17T22:49:18Z Oliver 1 Created page with "“Bulk Data” is a set of data such big in size, that standard mechanisms used to handle smaller data sets become inconvenient. This implies that bulk data in a software sys..." wikitext text/x-wiki “Bulk Data” is a set of data such big in size, that standard mechanisms used to handle smaller data sets become inconvenient. This implies that bulk data in a software system are modeled, stored, accessed and transported by different mechanisms than smaller data sets. Bulk data are typically handled by adding a level of abstraction (e.g. files) which separates the containment of the data from the internal structure. The critical size, above which data must be regarded as bulk data depends on the technical infrastructure (e.g. bus system) and the considered use case (transport, storage etc.). 097c71c87c4390334176d740215de6a22c62fdb5 0 123 134 2013-12-17T22:50:05Z Oliver 1 Created page with "A bus wake-up is caused by a specific wake pulse on the bus defined within the specification of the dedicated communication standard (e.g. [[CAN]], [[LIN]], [[FR]]). A bus wak..." wikitext text/x-wiki A bus wake-up is caused by a specific wake pulse on the bus defined within the specification of the dedicated communication standard (e.g. [[CAN]], [[LIN]], [[FR]]). A bus wake-up initiates that the [[transceiver]] and controller leave their energy saving mode and enter normal mode to start bus communication again. a044e6739b069d59a0a7a2137a82ab3a25ef4e05 0 124 135 2013-12-17T22:50:14Z Oliver 1 Created page with "Flexray" wikitext text/x-wiki Flexray e9f875bc83ba5c0092661f841e39975a86821b19 0 125 136 2013-12-17T22:51:38Z Oliver 1 Created page with "Calibration is the adjustment of parameters of Software Components ([[SW-C]]) realizing the control functionality (namely parameters of AUTOSAR SW-Cs, [[ECU]] abstraction or [..." wikitext text/x-wiki Calibration is the adjustment of parameters of Software Components ([[SW-C]]) realizing the control functionality (namely parameters of AUTOSAR SW-Cs, [[ECU]] abstraction or [[Complex Driver]]s). Only those software modules can be calibrated, which are above [[RTE]] and [[ECU]] Abstraction and [[CD]]. Calibration is always done at [[post-build]] time. Used techniques to set calibration data include end-of-line programming, garage programming and adaptive calibration (e.g. in the case of anti-pinch protection for power window). 441679029afc05a612d214a148dc62dc735f6fec 0 126 137 2013-12-17T22:52:53Z Oliver 1 Created page with "Functionality that is defined by an [[AUTOSAR module]] so that lower-level modules (i.e. lower in the Layered Software Architecture) can provide notification as required (e.g...." wikitext text/x-wiki Functionality that is defined by an [[AUTOSAR module]] so that lower-level modules (i.e. lower in the Layered Software Architecture) can provide notification as required (e.g. when certain events occur or asynchronous processing completes). In AUTOSAR, modules usually provide a register mechanism for callback functions which is set through configuration. A module provides callbacks so that other modules can initiate its processing while the module calls [[callout]]s to execute functionality that could not be specified by AUTOSAR, i.e. [[integration code]]. 012b1c90d301b0df3e52fb0205700a720f550b3f 0 127 138 2013-12-17T22:54:10Z Oliver 1 Created page with "Function stubs that the system designer can replace with code to add functionality to a [[module]] which could not be specified by AUTOSAR. A module calls callouts to execute ..." wikitext text/x-wiki Function stubs that the system designer can replace with code to add functionality to a [[module]] which could not be specified by AUTOSAR. A module calls callouts to execute functionality that could not be specified by AUTOSAR, i.e. [[integration code]] while the module provides [[callback]]s so that other modules can initiate its processing. Callouts can be separated into two classes: 1) callouts that provide mandatory functionality and thus serve as a [[hardware abstraction layer]] 2) callouts that provide optional functionality be8877c612254685866dc6b651284e4a3730ccf7 0 128 139 2013-12-17T22:54:56Z Oliver 1 Created page with "A point in a Software-Component where the [[SW-C]] enforce an execution entity ([[Entry point]]) in another SW-C." wikitext text/x-wiki A point in a Software-Component where the [[SW-C]] enforce an execution entity ([[Entry point]]) in another SW-C. d8ed0f4389e0be1916b1532b68e8ff31c9831d5b 0 129 140 2013-12-17T22:55:44Z Oliver 1 Created page with "Category 1 (Cat1) Interrupts are supported by the [[OS]] but their code is only allowed to call a very small subset of OS functions. Furthermore they can bypass the OS. The co..." wikitext text/x-wiki Category 1 (Cat1) Interrupts are supported by the [[OS]] but their code is only allowed to call a very small subset of OS functions. Furthermore they can bypass the OS. The code of Category 1 Interrupts depends (normally) on the used compiler and microcontroller. Category 1 Interrupts are not allowed to use the [[ISR]]() macro. Category 1 Interrupts need to implement/establish their own Interrupt Frame. Nevertheless they have to be configured in order to be included in the [[Interrupt Vector Table]]. 758899597c93a49bf615a4f063aef47c5db19df2 0 130 141 2013-12-17T22:56:13Z Oliver 1 Created page with "Category 2 (Cat2) Interrupts are supported by the [[OS]] and their code can call a subset of OS functions. The definition of the Cat2 Interrupt must use the [[ISR]]() macro in..." wikitext text/x-wiki Category 2 (Cat2) Interrupts are supported by the [[OS]] and their code can call a subset of OS functions. The definition of the Cat2 Interrupt must use the [[ISR]]() macro in order to be recognized by the OS. The Interrupt Frame of a Category 2 Interrupt is managed by the OS. 9492279623be4636da58a9dd7439c96336bd0f45 0 131 142 2013-12-17T22:57:10Z Oliver 1 Created page with "Transmit order of [[PDU]]s with the same identifier (instances of PDUs) from a source network is preserved in the destination network. Transmission of PDUs with the same ident..." wikitext text/x-wiki Transmit order of [[PDU]]s with the same identifier (instances of PDUs) from a source network is preserved in the destination network. Transmission of PDUs with the same identifier has a particular temporal order in a given source network. After routing over a gateway the temporal order of transmission of PDUs in a destination network may be changed. Only in case that the temporal order is the same, causality is given. Otherwise causality is violated. Causality can be in contradiction to prioritization of PDUs. 2f3233d967213cb69812d3c846484a7fe591b7dd 0 132 143 2013-12-17T22:57:53Z Oliver 1 Created page with "Software entity which uses services of a [[server]]. The client and the server might be located on one [[ECU]] or distributed on different calculation units (e.g. ECU, externa..." wikitext text/x-wiki Software entity which uses services of a [[server]]. The client and the server might be located on one [[ECU]] or distributed on different calculation units (e.g. ECU, external [[diagnostic tester]]). 7c70ba081a691d14597e2a571522b1f252179f15 0 133 144 2013-12-17T23:09:17Z Oliver 1 Created page with "A specific form of communication in a possibly distributed system in which software entities act as [[client]]s, [[server]]s or both, where 1...n clients are requesting [[serv..." wikitext text/x-wiki A specific form of communication in a possibly distributed system in which software entities act as [[client]]s, [[server]]s or both, where 1...n clients are requesting [[services]] via a specific protocol from typically one server. Client-server communication can be realized by [[synchronous communication]] or [[asynchronous communication]]. -Client takes initiative: requesting that the server performs a service, e.g. client triggers action within server (server does not start action on its own) -Client is after service request blocked / non-blocked -Client expects response from server: data flow (+ control flow, if blocked) One example for 1 client to n server communication (currently not supported) is a functional request by diagnosis. This has to be treated as a specific exception. 1f4fd75d1d73d89a15d6272e8dcb040d925a35ec 0 134 145 2013-12-17T23:10:40Z Oliver 1 Created page with "The client-server interface is a special kind of [[port-interface]] used for the case of [[client-server communication]]. The client-server interface defines the operations th..." wikitext text/x-wiki The client-server interface is a special kind of [[port-interface]] used for the case of [[client-server communication]]. The client-server interface defines the operations that are provided by the [[server]] and that can be used by the [[client]]. 2bdd560e3d8b7d84e64c617515068b5188fa67ad 0 135 146 2013-12-17T23:11:20Z Oliver 1 Created page with "A cluster signal represents the aggregating system signal on one specific communication cluster. Cluster signals can be defined independently of [[frame]]s. This allows a deve..." wikitext text/x-wiki A cluster signal represents the aggregating system signal on one specific communication cluster. Cluster signals can be defined independently of [[frame]]s. This allows a development [[methodology]] where the signals are defined first, and are assigned to frames in a later stage. 9737c37fbd4c694a21f09b1e5d73ca088c8443f6 0 136 147 2013-12-17T23:11:49Z Oliver 1 Created page with "The Code Generator consumes complete and correctly formed [[XML]] for a [[BSW]] module and generates code and data that configures the [[module]]." wikitext text/x-wiki The Code Generator consumes complete and correctly formed [[XML]] for a [[BSW]] module and generates code and data that configures the [[module]]. 903ae72130b39ccc7847eaee934382294d73fb10 0 137 148 2013-12-17T23:13:05Z Oliver 1 Created page with "Adaptation of [[SW]] by selection of functional alternatives according to external requirements. Code Variant Coding might influences [[RTE]] (Runtime Environment) and [[BSW]]..." wikitext text/x-wiki Adaptation of [[SW]] by selection of functional alternatives according to external requirements. Code Variant Coding might influences [[RTE]] (Runtime Environment) and [[BSW]] modules, not only the [[application software module]]s. Code Variant Coding is always done at [[pre-compile time]] or at [[link time]]. Code Variant Coding also includes vehicle-specific (not user-specific) SW adaptation due to end-customer wishes (e.g. deactivation of speed dependent automatic locking). da24245c599cebce5d6e158ef948eeac780a3584 0 138 149 2013-12-17T23:14:00Z Oliver 1 Created page with "Communication attributes define, according to the development phase, behavioral as well as implementation aspects of the AUTOSAR communication patterns. The exact characterist..." wikitext text/x-wiki Communication attributes define, according to the development phase, behavioral as well as implementation aspects of the AUTOSAR communication patterns. The exact characteristics of the communication patterns provided by AUTOSAR ([[client]]-[[server]] and [[sender]]-[[receiver]]) can be specified more precisely by communication attributes. 8d03c4c264b1369c045c6c227bc85672f5346842 0 29 150 32 2013-12-17T23:16:04Z Oliver 1 wikitext text/x-wiki Complex Driver An [[Atomic Software Component]] that on one side interfaces with the [[VFB]] and on the other side directly accesses [[Peripheral Hardware]] and/or [[ECU-Abstraction]] and/or [[MCAL]]. Complex Driver can be accessed via [[AUTOSAR Interface]]s and/or directly by Basic Software Modules ([[BSM]]). This [[SW]] situated below the AUTOSAR [[RTE]]. This software in general is not re-locatable. d1ec738a68ae50bb96edf77e41f2353fbb83fcc6 0 139 151 2013-12-17T23:17:57Z Oliver 1 Created page with "An AUTOSAR Composition encapsulates a collaboration of software components ([[SW-C]]), thereby hiding detail and allowing the creation of higher abstraction levels. Through [[..." wikitext text/x-wiki An AUTOSAR Composition encapsulates a collaboration of software components ([[SW-C]]), thereby hiding detail and allowing the creation of higher abstraction levels. Through [[Delegation Connectors]] a Composition explicitly specifies, which [[Port]]s of the internal components are visible from the outside. AUTOSAR Compositions are a type of Components, e.g. they can be part of further compositions. 1f49111b29a8c29c5cc2d8a54104f44afe500eb7 0 140 152 2013-12-17T23:21:15Z Oliver 1 Created page with "Compositionality is given when the behavior of a software component ([[SW-C]]) or subsystem of a system is independent of the overall system load and configuration. Compositio..." wikitext text/x-wiki Compositionality is given when the behavior of a software component ([[SW-C]]) or subsystem of a system is independent of the overall system load and configuration. Compositionality is an important [[property]] of [[deterministic system]]s. This property leads to a complete decoupling of systems. Smooth subsystem integration without backlashes is then easily achievable. 82a3ba9c77d4fbb1470ef2f95939f063e827ec56 0 141 153 2013-12-17T23:22:44Z Oliver 1 Created page with "The conditioned signal is the internal electrical representation of the electrical signal within the [[ECU]]. It is delivered to the processor and represented in voltage and t..." wikitext text/x-wiki The conditioned signal is the internal electrical representation of the electrical signal within the [[ECU]]. It is delivered to the processor and represented in voltage and time (or, in case of logical signals, by high or low level). The [[Electrical Signal]] usually can not be processed by the peripherals directly, but has to be adopted. This includes amplification and limitation, conversion from a current into a voltage and so on. This conversion is performed by some electronical devices in the ECU and the result of the conversion is called the Conditioned Signal. The description means for the Conditioned Signal can also be the same as for [[Technical Signals]] and Electrical Signals, but limited to electrical voltage. c458118d425442b32681e3e176e1445f0b1d7c4d 0 142 154 2013-12-17T23:23:15Z Oliver 1 Created page with "The arrangement of hardware and/or software [[element]]s in a system." wikitext text/x-wiki The arrangement of hardware and/or software [[element]]s in a system. 3707c34b121ded35f146f982d15f71c55b8ffd82 0 143 155 2013-12-17T23:24:21Z Oliver 1 Created page with "Service primitive defined in the ISO/OSI Reference model (ISO 7498). With the 'confirmation' service primitive a [[service provider]] informs a [[service user]] about the resu..." wikitext text/x-wiki Service primitive defined in the ISO/OSI Reference model (ISO 7498). With the 'confirmation' service primitive a [[service provider]] informs a [[service user]] about the result of a preceding [[service request]] of the service user [OSEK BD] A confirmation is e.g. a specific notification generated by the [[OSEK]] underlying layer to inform about a Message Transmission Error. b2c341a0112c2984af568a0cf8c85ca7f8c4fd3a 0 33 156 36 2013-12-18T21:41:09Z Oliver 1 wikitext text/x-wiki Conformance Test Agency This is an organization performing a role with specific tasks in the conformance test process. Two possibilities are distinguished, a [[third party]] CTA or a [[first party]] CTA (which is also a product supplier). The tasks/services provided by a CTA is: - Provision of a [[CTS]] - Test execution - Attestation of product conformance For a third party CTA the focus is on the attestation and for a first party the focus is on the test execution. 2b77f99bc2f0309aef39a3a64c28b86f712420dd 0 34 157 37 2013-12-18T21:41:56Z Oliver 1 wikitext text/x-wiki Conformance Test Suite Is a test implementation used in the context of Conformance Testing. Typically, multiple test implementations from different vendors (e.g. [[CTA]]) will exist, each of which implements the standardized Conformance Test specifications. ISO 9646 distinguishes between Abstract Test Suites and Executable Test Suites. For AUTOSAR the earlier relates to the Conformance Test Specifications, whereas the latter to the test implementations or Conformance Test Suites. 73b6edc0a1c398865b60ae106ab6a82a073658d0 0 144 158 2013-12-18T21:42:33Z Oliver 1 Created page with "A connector connects [[ports]] of software components ([[SW-C]]) and represents the flow of information between those ports." wikitext text/x-wiki A connector connects [[ports]] of software components ([[SW-C]]) and represents the flow of information between those ports. f3d7784382230809757af0890a966a5afc8373a4 0 133 159 144 2013-12-18T21:42:59Z Oliver 1 wikitext text/x-wiki A specific form of communication in a possibly distributed system in which software entities act as [[client]]s, [[server]]s or both, where 1...n clients are requesting [[services]] via a specific protocol from typically one server. Client-server communication can be realized by [[synchronous communication]] or [[asynchronous communication]]. -Client takes initiative: requesting that the server performs a service, e.g. client triggers action within server (server does not start action on its own) -Client is after service request blocked / non-blocked -Client expects response from server: data flow (+ [[control flow]], if blocked) One example for 1 client to n server communication (currently not supported) is a functional request by diagnosis. This has to be treated as a specific exception. ca7f36ddf10c591db57c46a6a8086899568e38df 164 159 2013-12-18T21:50:49Z Oliver 1 wikitext text/x-wiki A specific form of communication in a possibly distributed system in which software entities act as [[client]]s, [[server]]s or both, where 1...n clients are requesting [[services]] via a specific protocol from typically one server. Client-server communication can be realized by [[synchronous communication]] or [[asynchronous communication]]. -Client takes initiative: requesting that the server performs a service, e.g. client triggers action within server (server does not start action on its own) -Client is after service request blocked / non-blocked -Client expects response from server: [[data flow]] (+ [[control flow]], if blocked) One example for 1 client to n server communication (currently not supported) is a functional request by diagnosis. This has to be treated as a specific exception. 96ca47c2a1b006c353a1cf498dd9a0c65193a389 0 145 160 2013-12-18T21:48:39Z Oliver 1 Created page with "The directed transmission of information between multiple [[entity|entities]], directly resulting in a state change of the receiving entity. A state change could result in an ..." wikitext text/x-wiki The directed transmission of information between multiple [[entity|entities]], directly resulting in a state change of the receiving entity. A state change could result in an activation of a schedulable entity. d984e688add54e007e99629516c9109feefb52c7 0 146 161 2013-12-18T21:49:22Z Oliver 1 Created page with "To control and harmonize two or more [[event|events]] or [[operation|operations]] to act in an organized and predictable way." wikitext text/x-wiki To control and harmonize two or more [[event|events]] or [[operation|operations]] to act in an organized and predictable way. da77abdbba7ce6ed3c239679b66b42d4f1500698 187 161 2013-12-18T22:25:05Z Oliver 1 wikitext text/x-wiki To control and harmonize two or more [[event]]s or [[operation]]s to act in an organized and predictable way. 543ee5a5f36805bc17a366d7b04348b304309c7c 0 147 162 2013-12-18T21:49:39Z Oliver 1 Created page with "A reinterpretable representation of information in a formalized manner suitable for communication, interpretation or processing." wikitext text/x-wiki A reinterpretable representation of information in a formalized manner suitable for communication, interpretation or processing. 0502541f963090d40d7d230398d2bae8851b1b7c 0 148 163 2013-12-18T21:50:31Z Oliver 1 Created page with "Data elements are declared within the context of a [[Sender-Receiver Interface]]. They serve as the data units that are exchanged between [[sender]] and [[receiver]]." wikitext text/x-wiki Data elements are declared within the context of a [[Sender-Receiver Interface]]. They serve as the data units that are exchanged between [[sender]] and [[receiver]]. 457d724f31cab5ad8bc9c9405e09c1f14e662946 0 149 165 2013-12-18T21:51:33Z Oliver 1 Created page with "The directed transmission of [[data]] between multiple [[entity|entities]]. The transmitted data are not directly related to a state change at the [[receiver]] side." wikitext text/x-wiki The directed transmission of [[data]] between multiple [[entity|entities]]. The transmitted data are not directly related to a state change at the [[receiver]] side. 3a00771fbb4d638a19fa499e31c413cb2996d20b 0 150 166 2013-12-18T21:53:42Z Oliver 1 Created page with "Adaptation of [[SW]] by setup of certain characteristic [[data]] according to external requirements. Data Variant Coding might influences [[RTE]] (RunTimeEnvironment) and [[BS..." wikitext text/x-wiki Adaptation of [[SW]] by setup of certain characteristic [[data]] according to external requirements. Data Variant Coding might influences [[RTE]] (RunTimeEnvironment) and [[BSWM|BSW modules]] not only the [[application software]] modules. (Multiple configuration parameter sets are needed.) Variant Coding is always done at [[post-build]] time. Variant Coding also includes [[vehicle-specific]] (not [[user-specific]]) SW adaptation due to end-customer wishes (e.g. deactivation of speed dependent automatic locking). Used techniques to select variants include end-of-line programming and garage programming. The major difference with [[calibration]] is that this later doesn’t aim to adapt the SW functionality itself but only aims to adjust the characteristic data of the SW to the [[HW]]/SW environment. Characteristic data in the source code of a software function have a significant impact on the functionality of the software. 4b0642bce71f08f8be6cef6c66069a656fb63427 0 151 167 2013-12-18T21:54:00Z Oliver 1 Created page with "The point in time when an execution of an [[entity]] must be finished." wikitext text/x-wiki The point in time when an execution of an [[entity]] must be finished. 7a9a14fa7c84ad9878939f66143687bc4be7cbe0 0 152 168 2013-12-18T21:54:48Z Oliver 1 Created page with "Debugging is the process of gathering information in case of a [[SW|software]] problem. The information is used to analyze the software problem. To analyze and later fix a sof..." wikitext text/x-wiki Debugging is the process of gathering information in case of a [[SW|software]] problem. The information is used to analyze the software problem. To analyze and later fix a software problem, in many cases more information than the one provided by the software [[API]] is necessary. This can be for example the state of internal variables of the software or a trace of the communication. The information can be collected by different means, e.g. an emulator or a tracing tool for the [[communication bus]]. 39965613d87d8ecedce78ac172d07d4664deffa3 0 153 169 2013-12-18T21:55:13Z Oliver 1 Created page with "Dependability is defined as the trustworthiness of a computer system such that reliance can justifiable be placed on the service it delivers." wikitext text/x-wiki Dependability is defined as the trustworthiness of a computer system such that reliance can justifiable be placed on the service it delivers. 13e87dfd0985d4ec9dbe7eb25ce2a613d9600dab 0 154 170 2013-12-18T21:55:59Z Oliver 1 Created page with "The routing of signals or [[PDU|PDUs]] in a gateway can be changed throughout operation without change of the [[operation mode]] of the [[gateway]]. Dynamic routing requires t..." wikitext text/x-wiki The routing of signals or [[PDU|PDUs]] in a gateway can be changed throughout operation without change of the [[operation mode]] of the [[gateway]]. Dynamic routing requires the change of routing tables during operation. It is not intended to use dynamic routing in the gateway. 1ac0eb19f5550e8886f402672d836128a503a61c 0 155 171 2013-12-18T21:57:18Z Oliver 1 Created page with "A functional and complete description of a specific [[communication stack]] in terms of data structures, [[service|services]], behavioral state-machines, error handling. [[E2E..." wikitext text/x-wiki A functional and complete description of a specific [[communication stack]] in terms of data structures, [[service|services]], behavioral state-machines, error handling. [[E2E]] Profiles are defined in AUTOSAR [[E2E Library]]. An E2E Profile is configurable by runtime parameters. A specific set of runtime parameters is called E2E profile variant. In order to reach [[interoperability]], the application developers should use the E2E profile variants defined in the E2E library. 871181689d008b7cb525e205771e963af4006743 0 41 172 44 2013-12-18T21:58:07Z Oliver 1 wikitext text/x-wiki Electronic Control Unit In the AUTOSAR sense an ECU means a microcontroller plus peripherals and the according software/[[configuration]]. Therefore, each microcontroller requires its own ECU Configuration. b5916d64f493368739f62a0d205f03b68b0b9c24 174 172 2013-12-18T22:00:20Z Oliver 1 wikitext text/x-wiki Electronic Control Unit In the AUTOSAR sense an ECU means a microcontroller plus peripherals and the according software/[[configuration]]. Therefore, each microcontroller requires its own [[ECU Configuration]]. a7472d32976dfcb48cbb305b213a7e0ffad7835f 177 174 2013-12-18T22:18:33Z Oliver 1 Redirected page to [[Electronic Control Unit]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit]] 36e857917fdce8ea1b3a7e8262deb830a9919664 0 156 173 2013-12-18T21:59:56Z Oliver 1 Created page with "The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU and offers ..." wikitext text/x-wiki The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface). Task: make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: -I/O Hardware Abstraction -Communication Hardware Abstraction -Memory Hardware Abstraction -Onboard Device Abstraction Properties: -Implementation: [[uC]] independent, ECU hardware dependent -Upper Interface (API): uC and ECU hardware independent, dependent on signal type 62a05ebf6d2b3ac756c9505f79e457f3cb482c3c 0 157 175 2013-12-18T22:02:15Z Oliver 1 Created page with "Activity of integrating and configuring one [[ECU]]’s software. Further Explanations: ECU Configuration denotes the activity when one ECU's software is set up for a specific..." wikitext text/x-wiki Activity of integrating and configuring one [[ECU]]’s software. Further Explanations: ECU Configuration denotes the activity when one ECU's software is set up for a specific usage inside the ECU. In AUTOSAR the ECU Configuration activity is divided into [[Pre-compile time]], [[Link time]] and [[Post-build time]] configuration. d6d1745b62be2404781dd7e1171cf25db062db15 0 158 176 2013-12-18T22:04:10Z Oliver 1 Created page with "Output of the [[ECU Configuration]] activity containing the values of configuration parameters and references. [[ECU]] Configuration Description holds the configuration parame..." wikitext text/x-wiki Output of the [[ECU Configuration]] activity containing the values of configuration parameters and references. [[ECU]] Configuration Description holds the configuration parameter values and references to other [[module]]'s configurations which have been defined in the ECU Configuration activity. ECU Configuration Description may contain the whole ECU Configuration information or only the parts relevant for a specific configuration step (e.g. [[Pre-compile time]]). a7e7c7efefbf4a51b00228c8deaff6c5fbb55088 0 159 178 2013-12-18T22:18:45Z Oliver 1 Created page with "In the AUTOSAR sense an ECU means a microcontroller plus peripherals and the according software/[[configuration]]. Therefore, each microcontroller requires its own [[ECU Confi..." wikitext text/x-wiki In the AUTOSAR sense an ECU means a microcontroller plus peripherals and the according software/[[configuration]]. Therefore, each microcontroller requires its own [[ECU Configuration]]. 8dc3102f139cbb7dae1ed469cdbbfca48705a85a 0 160 179 2013-12-18T22:20:11Z Oliver 1 Created page with "The electrical signal is the electrical representation of [[technical signal]]s. Electrical signals can only be represented in voltage, current and time. When a sensor process..." wikitext text/x-wiki The electrical signal is the electrical representation of [[technical signal]]s. Electrical signals can only be represented in voltage, current and time. When a sensor processes the Technical Signal it is converted into an Electrical Signal. The information can be provided in the current, the voltage or in the timely change of the signal (e.g. a pulse width modulation). 49775af992f46772d8d59b234b6f61d75fd1505e 0 161 180 2013-12-18T22:20:51Z Oliver 1 Created page with "Any C function defined by an AUTOSAR specification which does not implement or alter behavior required to accomplish the assigned functional responsibility. As such an empty f..." wikitext text/x-wiki Any C function defined by an AUTOSAR specification which does not implement or alter behavior required to accomplish the assigned functional responsibility. As such an empty function in the context of AUTOSAR can still have code but this code shall not impact the state machine other than error reporting. Auxiliary code like validating arguments to report to the [[DET]] does not constitute functional behavior because without the code and proper calling this code would still fulfill its architectural responsibility. 1f9b23036155f10e3f6b67c2d3e143a07a2a6449 0 11 181 13 2013-12-18T22:21:27Z Oliver 1 Redirected page to [[Development Error Tracer]] wikitext text/x-wiki #REDIRECT [[Development Error Tracer]] c8a925f52c75fb95a31a1d9721e97aeeee532de2 0 162 182 2013-12-18T22:21:34Z Oliver 1 Created page with "Development Error Tracer module to which development errors are reported." wikitext text/x-wiki Development Error Tracer module to which development errors are reported. ae1192bd1a8fd90996d071d20c5a389d0f2f1d07 0 163 183 2013-12-18T22:22:26Z Oliver 1 Created page with "A point in a [[Software-Component]] where an execution entity of the [[SW-C]] begins." wikitext text/x-wiki A point in a [[Software-Component]] where an execution entity of the [[SW-C]] begins. aacfb14b1566af35661220828ecf10d8283c3c47 0 86 184 89 2013-12-18T22:22:56Z Oliver 1 Redirected page to [[Software Component]] wikitext text/x-wiki #REDIRECT [[Software Component]] 1b400e021eae68abe0c8a724614f9c7de4209b9a 0 164 185 2013-12-18T22:24:11Z Oliver 1 Created page with "Discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition. An error can arise as a result of..." wikitext text/x-wiki Discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition. An error can arise as a result of unforeseen operating conditions or due to a fault within the system, [[subsystem]] or [[component]] being considered. A fault can manifest itself as an error within the considered [[element]] and, at the end of its latency, the error can cause a failure. ec19a57e6177ab8262e6a0cd6f0c66f47d6eb409 197 185 2013-12-18T22:30:50Z Oliver 1 wikitext text/x-wiki Discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition. An error can arise as a result of unforeseen operating conditions or due to a fault within the system, [[subsystem]] or [[component]] being considered. A fault can manifest itself as an error within the considered [[element]] and, at the end of its latency, the error can cause a [[failure]]. 0ac5b3b0fc99146616d635656395380611b59b5e 200 197 2013-12-18T22:32:23Z Oliver 1 wikitext text/x-wiki Discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition. An error can arise as a result of unforeseen operating conditions or due to a [[fault]] within the system, [[subsystem]] or [[component]] being considered. A fault can manifest itself as an error within the considered [[element]] and, at the end of its latency, the error can cause a [[failure]]. 98df73fef0bf96b4fa3abf49fcca69dae5d0b3b7 0 165 186 2013-12-18T22:24:31Z Oliver 1 Created page with "Ratio between detected lost/faulty words/symbols/blocks, divided by the total number of symbols/words/blocks sent." wikitext text/x-wiki Ratio between detected lost/faulty words/symbols/blocks, divided by the total number of symbols/words/blocks sent. d4e5507d4a03ea211a7f1304a75f524e5ab0e0e9 0 166 188 2013-12-18T22:25:25Z Oliver 1 Created page with "State change of a hardware and/or software entity." wikitext text/x-wiki State change of a hardware and/or software entity. 4cda06c8763420e70bbc820bf6306bef71633052 0 96 189 99 2013-12-18T22:26:53Z Oliver 1 wikitext text/x-wiki Worst Case [[Execution Time]]. 97489d823550845de7299f91f7e09a4af55e13e0 0 167 190 2013-12-18T22:27:40Z Oliver 1 Created page with "The time during which a program is actually executing, or more precisely during which a certain [[thread]] of execution is active. The execution time of software is the time d..." wikitext text/x-wiki The time during which a program is actually executing, or more precisely during which a certain [[thread]] of execution is active. The execution time of software is the time during which the [[CPU]] is executing its instructions. The time the CPU spends on [[task]] switches or on the execution of other pieces of software is not considered here. 712b886c56245cff7eba251d1798b72c08d447ff 0 168 191 2013-12-18T22:28:00Z Oliver 1 Created page with "A point in a [[Software-Component]] where an execution entity of the SW-C ends." wikitext text/x-wiki A point in a [[Software-Component]] where an execution entity of the SW-C ends. 48e0d87f12d605862f4408b1ab23d1383262abfc 0 169 192 2013-12-18T22:28:24Z Oliver 1 Redirected page to [[Software Component]] wikitext text/x-wiki #REDIRECT [[Software Component]] 1b400e021eae68abe0c8a724614f9c7de4209b9a 0 170 193 2013-12-18T22:29:08Z Oliver 1 Created page with "Property of a [[system]] or [[functional unit]]. Describes the ability of a system to continue with intended degraded operation at its output interfaces despite the presence o..." wikitext text/x-wiki Property of a [[system]] or [[functional unit]]. Describes the ability of a system to continue with intended degraded operation at its output interfaces despite the presence of hardware or software faults. 51c253efbaf12977c7f61318de2c22d0cb184a8a 0 171 194 2013-12-18T22:29:35Z Oliver 1 Created page with "Property of a [[system]] or [[functional unit]]. Describes the ability of a system or functional unit to continue normal operation at its output interfaces despite the presenc..." wikitext text/x-wiki Property of a [[system]] or [[functional unit]]. Describes the ability of a system or functional unit to continue normal operation at its output interfaces despite the presence of hardware or software faults. 7203c5d166254cf7a7e1b6befd15bf682a60a3a9 0 172 195 2013-12-18T22:30:04Z Oliver 1 Created page with "Property of a [[system]] or [[functional unit]]. In case of a fault the system or functional unit transits to a [[safe state]]." wikitext text/x-wiki Property of a [[system]] or [[functional unit]]. In case of a fault the system or functional unit transits to a [[safe state]]. 9d0d1e97f1ee45ef7f1e7e620b1cec4d64a4d30e 0 173 196 2013-12-18T22:30:32Z Oliver 1 Created page with "Property of a [[system]] or [[functional unit]]. In case of a fault the output interfaces are disabled in a way that no further outputs are made." wikitext text/x-wiki Property of a [[system]] or [[functional unit]]. In case of a fault the output interfaces are disabled in a way that no further outputs are made. fad7b339a9a0eccfaa7ef28e707a7a4e09a5986a 0 174 198 2013-12-18T22:31:29Z Oliver 1 Created page with "Termination of the ability of an [[element]] or an [[item]] to perform a function as required. Termination is a reduction in, or loss of, ability of an element or an item to p..." wikitext text/x-wiki Termination of the ability of an [[element]] or an [[item]] to perform a function as required. Termination is a reduction in, or loss of, ability of an element or an item to perform a function as required. There is a difference between “to perform a function as required” (stronger definition, use-oriented) and ”to perform a function as specified”, so a failure can result from an incorrect specification. 3bf7d03a8c027a4eac9740addec2894cc2601cd7 0 175 199 2013-12-18T22:31:59Z Oliver 1 Created page with "Frequency of occurrence of an error measured within a specific period. It is usually expressed in [1e9 * h-¹] = [FIT], which means how many faults happen within 1.000.000.000..." wikitext text/x-wiki Frequency of occurrence of an error measured within a specific period. It is usually expressed in [1e9 * h-¹] = [FIT], which means how many faults happen within 1.000.000.000 hours. Error rates can be determined by physical/mathematical models and by tracking of failures of already produced units. 00c4c6303cb2980369eac42ca3c90b3cf69ff8d0 0 172 201 195 2013-12-18T22:32:38Z Oliver 1 wikitext text/x-wiki Property of a [[system]] or [[functional unit]]. In case of a [[fault]] the system or functional unit transits to a [[safe state]]. 3ecb30e3893108850eb1997bcb7188c4e6c8827e 0 173 202 196 2013-12-18T22:32:50Z Oliver 1 wikitext text/x-wiki Property of a [[system]] or [[functional unit]]. In case of a [[fault]] the output interfaces are disabled in a way that no further outputs are made. b405b75f64a147bfa2ec0826b0e76e2d1e5845e2 0 124 215 135 2013-12-18T22:32:58Z Oliver 1 Redirected page to [[Flexray]] wikitext text/x-wiki #REDIRECT [[Flexray]] 3d8972976d9b895e27a2f01850cd835d7bd6213e 0 176 203 2013-12-18T22:33:05Z Oliver 1 Created page with "Abnormal condition that can cause an [[element]] or an [[item]] to fail." wikitext text/x-wiki Abnormal condition that can cause an [[element]] or an [[item]] to fail. 18a870c4e4cd099764e22a1aa2e5938872432454 0 177 204 2013-12-18T22:35:24Z Oliver 1 Created page with "The action of monitoring errors and setting [[fault]] states to specific values is called [[fault]] detection. The different states are called “not detected”/ “present..." wikitext text/x-wiki The action of monitoring errors and setting [[fault]] states to specific values is called [[fault]] detection. The different states are called “not detected”/ “present”/ ”intermittent or maturing”/… The names of the fault states are following the ISO/SAE norms; however there is a coordination step in between the states of the [[DTC]]s (Diagnostic Trouble Code) and the states of the faults. The [[SW-C]]’s Fault Detection is executed decentralized, e.g. each SW-C sets the state of a fault according to the defined fault qualification ([[SW-C Template]]). Therefore the Fault Detection is implemented in the SW-C (SW-C could be either [[Application SW Component]] or [[BSWM|Basic SW Component]]). There are exceptions; these will be pointed out individually for each fault. The SW-C’s developer will define the conditions (=fault qualification), when these conditions are fulfilled the SW-C notifies a fault to the [[Diagnostic Memory Management]]. 977d4da7bd146736c2679e4c09cc76d040ac9b23 0 186 217 2013-12-18T22:35:33Z Oliver 1 Created page with "One element in a [[FlexRay Matrix]] unequivocally defined by a combination of exactly one [[FlexRay Slot]] (or [[FlexRay Slot Number]]) and exactly one [[FlexRay Cycle]] (or [..." wikitext text/x-wiki One element in a [[FlexRay Matrix]] unequivocally defined by a combination of exactly one [[FlexRay Slot]] (or [[FlexRay Slot Number]]) and exactly one [[FlexRay Cycle]] (or [[FlexRay Cycle Number]]). In other words: a [[FlexRay]] Cell is defined by the tuple <Slot Number, Cycle Number>. Each FlexRay Cell represents one (possible) transmission time interval for at most one [[FlexRay Frame]]. If a [[FlexRay Network]] consists of two [[Channel]]s, there is one FlexRay Matrix per Channel , so there are also two FlexRay Cells defined by the same tuple <Slot Number, Cycle Number>, one for “Channel A” and one for “Channel B”. 7a0834416a03d14ac720f463230d68ea147d2762 232 217 2013-12-22T20:08:00Z Oliver 1 wikitext text/x-wiki One element in a [[FlexRay Matrix]] unequivocally defined by a combination of exactly one [[FlexRay Slot]] (or [[FlexRay Slot Number]]) and exactly one [[FlexRay Cycle]] (or [[FlexRay Cycle Number]]). In other words: a [[FlexRay Cell]] is defined by the tuple <Slot Number, Cycle Number>. Each [[FlexRay]] Cell represents one (possible) transmission time interval for at most one [[FlexRay Frame]]. If a [[FlexRay Network]] consists of two [[Channel]]s, there is one FlexRay Matrix per Channel , so there are also two FlexRay Cells defined by the same [[tuple]] <Slot Number, Cycle Number>, one for “Channel A” and one for “Channel B”. 3ec2d2745e41031969a1bea4c3c31a019c883e56 0 178 205 2013-12-18T22:35:47Z Oliver 1 Created page with "In case of a [[Failure]] of a [[SW-C]] there is a specific action to be carried out. This action is called “Fault Reaction”." wikitext text/x-wiki In case of a [[Failure]] of a [[SW-C]] there is a specific action to be carried out. This action is called “Fault Reaction”. 49034f4361b0385d23b44018248c76df1fcfcaea 0 179 206 2013-12-18T22:36:11Z Oliver 1 Created page with "Property of a [[system]] or [[functional unit]]. In case of n [[fault]]s the system or functional unit continues with full functionality (n>0)." wikitext text/x-wiki Property of a [[system]] or [[functional unit]]. In case of n [[fault]]s the system or functional unit continues with full functionality (n>0). c42c06052306f4596d1e3d5d2490a8794f84f424 0 187 218 2013-12-18T22:36:27Z Oliver 1 Created page with "The [[inter-Node]] connection through which [[signal]]s are conveyed for the purpose of communication. The communication channel abstracts both the [[network topology]], i.e.,..." wikitext text/x-wiki The [[inter-Node]] connection through which [[signal]]s are conveyed for the purpose of communication. The communication channel abstracts both the [[network topology]], i.e., [[Bus]] or [[Star]], as well as the [[physical transmission medium]], i.e. electrical or optical. a2d21b6716780bd1cbab2a68adb01647b008bd79 219 218 2013-12-18T22:37:03Z Oliver 1 wikitext text/x-wiki The [[inter-Node]] connection through which [[signal]]s are conveyed for the purpose of communication. The communication channel abstracts both the [[network topology]], i.e., [[Bus]] or [[Star]], as well as the [[physical transmission medium]], i.e. electrical or optical. According to the [[FlexRay Protocol Specification]], the two possible Channels of a [[FlexRay Network]] are named “Channel A” and “Channel B”. 6070c357062368ebad1205dbeddcbc8fd3b1cd07 0 180 207 2013-12-18T22:36:33Z Oliver 1 Created page with "The term feature is commonly used in the [[software tool]] community to describe characteristics (functionality) of the software." wikitext text/x-wiki The term feature is commonly used in the [[software tool]] community to describe characteristics (functionality) of the software. 178a63c12d54e84aacd1a710e4d64fae9c97d3b6 208 207 2013-12-18T22:37:03Z Oliver 1 wikitext text/x-wiki The term feature is commonly used in the [[software tool]] community to describe characteristics (functionality) of the software. In AUTOSAR a feature is represented by one or many meta classes and their attributes in the AUTOSAR [[meta-model]]. Features are used to implement use cases such that a single use case requires one or more features for implementation. 4fd2ab43864389c91bfbd87391fe9fd1b1878c38 0 188 220 2013-12-18T22:37:43Z Oliver 1 Created page with "A communication system of multiple [[Node]]s connected directly ([[Bus]] topology) or by [[Star]] Couplers (Star topology) via a Communication Network consisting of at least o..." wikitext text/x-wiki A communication system of multiple [[Node]]s connected directly ([[Bus]] topology) or by [[Star]] Couplers (Star topology) via a Communication Network consisting of at least one Communication Channel. efb9dccf616c43c3e039d9fe1358676e5b3ca9ab 0 110 209 115 2013-12-18T22:37:49Z Oliver 1 wikitext text/x-wiki Issue of a statement, based on a decision following a [[review]], that fulfillment of specified requirements has been demonstrated. The resulting statement, referred to in the International Standard as a "statement of conformity", conveys the assurance that the specified requirements have been fulfilled. Such an assurance does not, of itself, afford contractual or other legal guarantees. Attestation of product conformance given by a [[third party]] like a [[CTA]]. Attestation of product conformance given by a [[first party]] like the Product Supplier (also called declaration). e96ad2f2de061ff2fb4eaea5e4a70b61210acd81 0 181 210 2013-12-18T22:38:16Z Oliver 1 Created page with "An organization that provides automotive products, which are subject to AUTOSAR [[conformance testing]]." wikitext text/x-wiki An organization that provides automotive products, which are subject to AUTOSAR [[conformance testing]]. 430822dac9d9fb94f35b9039f85d31c05c8103df 0 182 211 2013-12-18T22:38:33Z Oliver 1 Created page with "A piece of data that can take on one of two values indicating whether a logical condition is true or false." wikitext text/x-wiki A piece of data that can take on one of two values indicating whether a logical condition is true or false. 4ae98fcf1fb383ff9af1e8b1027ccfb4d2849413 0 189 221 2013-12-18T22:38:36Z Oliver 1 Created page with "One complete instance of the communication structure that is periodically repeated to comprise the media access method of the [[FlexRay]] system. The Communication Cycle consi..." wikitext text/x-wiki One complete instance of the communication structure that is periodically repeated to comprise the media access method of the [[FlexRay]] system. The Communication Cycle consists of a Static Segment, an optional Dynamic Segment, an optional Symbol Window, and a Network Idle Time. The FlexRay Cycles are unequivocally numbered by the [[FlexRay Cycle Number]] ranging from 0 to 63. Even if a [[FlexRay Network]] consists of two Channels, the FlexRay Cycle is always a common quantity of both Channels, irrespective of the data transmission schedule possibly being different for the two Channels. e67847b8f35c9e9bdcfcbfe73ea7e219a5d64571 0 190 222 2013-12-18T22:38:58Z Oliver 1 Created page with "An unequivocal number of a [[FlexRay Cycle]], ranging from 0 to 63." wikitext text/x-wiki An unequivocal number of a [[FlexRay Cycle]], ranging from 0 to 63. b8154e4e955fd6c9f17a197b388ae3598d39262b 0 191 223 2013-12-18T22:39:30Z Oliver 1 Redirected page to [[FlexRay Cycle Number]] wikitext text/x-wiki #REDIRECT [[FlexRay Cycle Number]] 89588c5a0a4bef950a907079f782b92db0ea8cc8 0 192 224 2013-12-18T22:40:31Z Oliver 1 Redirected page to [[Base Cycle]] wikitext text/x-wiki #REDIRECT [[Base Cycle]] c7686725a833519d86081de43f066cc70c17cd5d 0 183 212 2013-12-18T22:40:40Z Oliver 1 Created page with "One operand of the equation used to calculate the [[Cycle Number]]s of the [[FlexRay Cell]]s being used for periodic transmission of [[FlexRay Frame]]s in a given [[FlexRay Sl..." wikitext text/x-wiki One operand of the equation used to calculate the [[Cycle Number]]s of the [[FlexRay Cell]]s being used for periodic transmission of [[FlexRay Frame]]s in a given [[FlexRay Slot]]. Equation: Definition Cycle Number = (B + n * 2R)mod64 Where:  Base Cycle B = 0 … 63  Cycle Repetition 2R = 20 … 26 = 1, 2, 4, 8, … 64  Variable n = 0 … 64  B < 2R (See also graphic in FlexRay [[L-SDU-Identifier]]) 89682e6a951ba0f218b85b8a17f01d9b7bd82f1f 0 193 225 2013-12-18T22:40:48Z Oliver 1 Redirected page to [[FlexRay Cycle Offset]] wikitext text/x-wiki #REDIRECT [[FlexRay Cycle Offset]] 0205392b7b3b2e77cafea963a97f2c247d8228c4 0 184 213 2013-12-18T22:41:10Z Oliver 1 Redirected page to [[Flexray]] wikitext text/x-wiki #REDIRECT [[Flexray]] 3d8972976d9b895e27a2f01850cd835d7bd6213e 0 194 226 2013-12-18T22:41:57Z Oliver 1 Created page with "One operand of the equation used to calculate the [[Cycle Number]]s of the [[FlexRay Cell]]s being used for periodic transmission of [[FlexRay Frame]]s in a given [[FlexRay Sl..." wikitext text/x-wiki One operand of the equation used to calculate the [[Cycle Number]]s of the [[FlexRay Cell]]s being used for periodic transmission of [[FlexRay Frame]]s in a given [[FlexRay Slot]]. Equation: Cycle Number = (B + n * 2R)mod64 Where:  Base Cycle B = 0 … 63  Cycle Repetition 2R = 20 … 26 = 1, 2, 4, 8, … 64  Variable n = 0 … 64  B < 2R (See also graphic in FlexRay [[L-SDU-Identifier]]) d87a91b9b51156e5b0fe42c7cb6b43852f6d1c3f 0 195 227 2013-12-18T22:42:50Z Oliver 1 Created page with "A structure used by the communication system to exchange information within the system. A [[FlexRay]] Frame consists of a header segment, a payload segment and a trailer segme..." wikitext text/x-wiki A structure used by the communication system to exchange information within the system. A [[FlexRay]] Frame consists of a header segment, a payload segment and a trailer segment. The payload segment is used to convey application data. A FlexRay Frame is a “data package” that may be transmitted within a [[FlexRay Cell]]. 305c78cf684f9422a1846fc98cd1b7ff4849818b 0 196 228 2013-12-18T22:43:06Z Oliver 1 Redirected page to [[FlexRay Frame]] wikitext text/x-wiki #REDIRECT [[FlexRay Frame]] a26271714bb5e0ec078dfc68e9fb5f673c6cde3e 0 197 229 2013-12-18T22:43:40Z Oliver 1 Created page with "A [[tuple]] consisting of one specific value of the [[FlexRay Cycle Counter]] and one specific value of the [[FlexRay Cycle Time]] in [[Macroticks]]." wikitext text/x-wiki A [[tuple]] consisting of one specific value of the [[FlexRay Cycle Counter]] and one specific value of the [[FlexRay Cycle Time]] in [[Macroticks]]. b951625a9cf2c23993cee5ed5347f027d264721c 0 198 230 2013-12-18T22:45:01Z Oliver 1 Created page with "A unequivocal identifier of a set of [[FlexRay Cell]]s used for periodic transmission of [[FlexRay Frame]]s over one or both [[FlexRay Channel]]s in a specific [[FlexRay Slot]..." wikitext text/x-wiki A unequivocal identifier of a set of [[FlexRay Cell]]s used for periodic transmission of [[FlexRay Frame]]s over one or both [[FlexRay Channel]]s in a specific [[FlexRay Slot]], which fulfill the equation: Cycle Number = (B + n * 2R)mod64 Definition with exactly one tuple of values for B and 2R. In other words: a FlexRay L-PDU-ID comprises the 4 parameters:  Slot Number = 1 … MaxSlotNumber (≤ 2047)  Base Cycle B = 0 … 63  Cycle Repetition 2R = 20 … 26 = 1, 2, 4, 8, … 64  Channel = “A”, “B”, “A and B” In order to prevent collisions of FlexRay Frames on the [[Bus]], the FlexRay Cells of different FlexRay L-PDU-Identifiers used for transmission shall be disjunctive. 5c0190a1a41cf69a97beab7765ea965de4e7d538 0 199 231 2013-12-22T20:07:00Z Oliver 1 Created page with "A unequivocal identifier of the [[payload]] contained in one or multiple [[FlexRay Frame]]s assigned to the same [[FlexRay L-PDU-Identifier]] and therefore periodically transm..." wikitext text/x-wiki A unequivocal identifier of the [[payload]] contained in one or multiple [[FlexRay Frame]]s assigned to the same [[FlexRay L-PDU-Identifier]] and therefore periodically transmitted over one or both [[FlexRay Channel]]s in one or multiple [[FlexRay Cell]]s in a specific [[FlexRay Slot]], and where the equation: Cycle Number = (B + n * 2^R)mod64 is fulfilled with exactly one [[tuple]] of values for B and 2^R. ed229c94ba75d95b851a193caeeff1dd4991a15f 0 200 233 2013-12-22T20:09:18Z Oliver 1 Created page with "A two-dimensional array with a width of the number of [[FlexRay Slot]]s within one [[FlexRay Cycle]] and a height of 64 FlexRay Cycles, numbered 0 … 63. This array is being ..." wikitext text/x-wiki A two-dimensional array with a width of the number of [[FlexRay Slot]]s within one [[FlexRay Cycle]] and a height of 64 FlexRay Cycles, numbered 0 … 63. This array is being used to describe the (possible) transmission time intervals on a [[FlexRay Channel]]. If a [[FlexRay Network]] consists of two Channels, there is one FlexRay Matrix per Channel (resulting in a total of two Matrixes), since the data transmission schedule may be different for the two FlexRay Channels. 72e08b0b07a5bec2908a5572ea9e75170bacce1e 0 201 234 2013-12-22T20:10:18Z Oliver 1 Created page with "The combination of the (up to two) [[FlexRay Communication Channel]]s that connect the [[FlexRay Node]]s of a [[FlexRay Cluster]]. The term “FlexRay Network” is not to be ..." wikitext text/x-wiki The combination of the (up to two) [[FlexRay Communication Channel]]s that connect the [[FlexRay Node]]s of a [[FlexRay Cluster]]. The term “FlexRay Network” is not to be confused with the term “[[FlexRay Cluster]]” or “[[FlexRay Bus]]”. feb062e28b40c5bdb7a265084a0e3f797c207042 0 202 235 2013-12-22T20:10:43Z Oliver 1 Created page with "A logical entity connected to the [[FlexRay Network]] that is capable of sending and/or receiving frames." wikitext text/x-wiki A logical entity connected to the [[FlexRay Network]] that is capable of sending and/or receiving frames. 52bdd97104cdf587ebd52e5c7cb9b1922cc6d8a5 0 203 236 2013-12-22T20:12:17Z Oliver 1 Created page with "An [[inter-Node]] connection through which signals are conveyed for the purpose of communication. All Nodes connected to a given Physical Communication Link share the same [[e..." wikitext text/x-wiki An [[inter-Node]] connection through which signals are conveyed for the purpose of communication. All Nodes connected to a given Physical Communication Link share the same [[electrical signal]]s or [[optical signal]]s (i.e., they are not connected through [[repeaters]], [[Stars]], [[gateway]]s, etc.). Examples of a Physical Communication Link include a [[Bus]] Network or a [[point-to-point connection]] between a Node and a Star. A Communication Channel may be constructed by combining one or more Physical Communication Links together using Stars. 774ea234427fe8b93910eec0188ea9df7f84849a 0 204 237 2013-12-22T20:15:16Z Oliver 1 Created page with "An interval of time during which access to a [[Communication Channel]] is granted exclusively (at least in the static segment) to a specific [[Node]] for the transmission of a..." wikitext text/x-wiki An interval of time during which access to a [[Communication Channel]] is granted exclusively (at least in the static segment) to a specific [[Node]] for the transmission of a [[Frame]] with a [[frame ID]] corresponding to the [[Slot Number]] of that Slot. [[FlexRay]] distinguishes between [[Static Communication Slot]]s and [[Dynamic Communication Slot]]s. The FlexRay Slots are unequivocally numbered by the [[FlexRay Slot Number]] ranging from 1 to a configurable maximum number ≤ 2047. If a [[FlexRay Network]] consists of two [[Channel]]s, the Static Slots of “Channel A” and the Static Slots of “Channel B” occur concurrently, since all Static FlexRay Slots have the same length irrespective of the data [[transmission schedule]]. However, the Dynamic Slots of “Channel A” are independent from the Dynamic Slots of “Channel B”, since the data transmission schedule may be different for the two FlexRay Channels. In the dynamic segment, [[Slot Multiplexing]] between multiple Nodes is allowed. In the static segment each Slot on a Channel is owned by exactly one Node (i.e., Slot Multiplexing is not allowed in the static segment). Slot Multiplexing (i.e., different FlexRay Nodes owning a Slot in different [[Cycle]]s for data transmission) is allowed in the dynamic segment, and it is up to the application to ensure that in any given Cycle no two Nodes transmit in the same Slot on the same Channel. 97a08e522611b8e94c44024b2f342bc1f0a8d3ee 0 214 247 2013-12-22T20:18:16Z Oliver 1 Created page with "1. A [[task]], action or activity that must be accomplished to achieve a desired outcome. 2. A part of programming code that is invoked by other parts of the program to fulfil..." wikitext text/x-wiki 1. A [[task]], action or activity that must be accomplished to achieve a desired outcome. 2. A part of programming code that is invoked by other parts of the program to fulfill a desired purpose. 3. In mathematics, a function is an association between two sets of values in which each element of one set has one assigned element in the other set so that any element selected becomes the independent variable and its associated element is the dependent variable. Due to the different meanings in texts using the term application the appropriate meaning should be explained in detail or referenced. 892b172ffaad28cc34cfd2ab6b0a48d12113853f 0 215 248 2013-12-22T20:18:48Z Oliver 1 Created page with "A logical structure of [[interconnection]]s between defined functional parts of [[feature]]s." wikitext text/x-wiki A logical structure of [[interconnection]]s between defined functional parts of [[feature]]s. 3105e4ddbb7bc14274a7dedb30e0720f1a6a00a3 0 216 249 2013-12-22T20:19:11Z Oliver 1 Created page with "An entity of software or hardware, or both, capable of accomplishing a specified purpose." wikitext text/x-wiki An entity of software or hardware, or both, capable of accomplishing a specified purpose. 235a72d6cf835a9edbcb5686a6a571205275c2f8 0 217 250 2013-12-22T20:19:35Z Oliver 1 Created page with "Functionality comprises User-visible and User-non-visible functional aspects of a system." wikitext text/x-wiki Functionality comprises User-visible and User-non-visible functional aspects of a system. 46f4d909a1df77ce32275bd90f32e8ad710d08a1 0 131 251 142 2013-12-22T20:20:06Z Oliver 1 wikitext text/x-wiki Transmit order of [[PDU]]s with the same identifier (instances of PDUs) from a source network is preserved in the destination network. Transmission of PDUs with the same identifier has a particular temporal order in a given source network. After routing over a [[gateway]] the temporal order of transmission of PDUs in a destination network may be changed. Only in case that the temporal order is the same, causality is given. Otherwise causality is violated. Causality can be in contradiction to prioritization of PDUs. f6a8f30a797bf31ee7463f23f706217692ce0267 0 218 252 2013-12-22T20:20:38Z Oliver 1 Created page with "A gateway is functionality within an [[ECU]] that performs a frame or signal mapping function between two [[communication system]]s. Communication system in this context means..." wikitext text/x-wiki A gateway is functionality within an [[ECU]] that performs a frame or signal mapping function between two [[communication system]]s. Communication system in this context means e.g. a [[CAN]] system or one channel of a [[FlexRay]] system. 82e4463bc34f4f6fc583149e53ffcca4296a4962 0 219 253 2013-12-22T20:21:14Z Oliver 1 Created page with "A [[gateway]] ECU is an [[ECU]] that is connected to two or more [[communication channel]]s, and performs gateway functionality." wikitext text/x-wiki A [[gateway]] ECU is an [[ECU]] that is connected to two or more [[communication channel]]s, and performs gateway functionality. a934e168983bc2a4fe80140b7ab97594f08a2b09 0 220 254 2013-12-22T20:22:37Z Oliver 1 Created page with "Hardware Connections are used to describe the connection of [[HW element]]s among each other. It defines/characterizes the interrelationship among HW Elements (for abstract mo..." wikitext text/x-wiki Hardware Connections are used to describe the connection of [[HW element]]s among each other. It defines/characterizes the interrelationship among HW Elements (for abstract modeling). The [[HW Port]]s of the HW Elements serve as connection points for this purpose. In AUTOSAR are 2 kinds of HW Connections defined: [[Assembly]] HW Connection [[Delegation]] HW Connection 3a2a4b76ad2450cff6567d1a0c3126f6de5c9c93 0 205 238 2013-12-22T20:22:57Z Oliver 1 Created page with "A method used to fill a [[FlexRay Slot]] on a [[Channel]] more efficiently by alternating the [[Frame]]s being sent in this Slot from [[Cycle]] to Cycle. In order to achieve p..." wikitext text/x-wiki A method used to fill a [[FlexRay Slot]] on a [[Channel]] more efficiently by alternating the [[Frame]]s being sent in this Slot from [[Cycle]] to Cycle. In order to achieve periodic transmission of [[FlexRay Frame]]s in a given FlexRay Slot, the [[Cycle Number]]s of the [[FlexRay Cell]]s being used for transmission have to fulfill the equation: Cycle Number = (B + n * 2^R)mod64 Where:  Base Cycle B = 0 … 63  Cycle Repetition 2^R = 2^0 … 2^6 = 1, 2, 4, 8, … 64  Variable n = 0 … 64  B < 2^R In the static segment, each Slot on a Channel is owned by exactly one Node. Therefore, in the static segment Slot Multiplexing is only allowed amongst semantically different Frames sent by the same Node, but not amongst different Nodes of a [[FlexRay Cluster]]. Thus, this form of Multiplexing is called "Single Sender Slot Multiplexing". In the dynamic segment, Slot Multiplexing is also allowed amongst different Nodes of a FlexRay Cluster, i.e. different Nodes may send in the same dynamic Slot on the same Channel in different Cycles, hence with different [[FlexRay L-PDU-Identifier]] defining disjunctive FlexRay Cells. Thus, this form of Multiplexing is called "Multiple Sender Slot Multiplexing". In any case, it is up to the software to prevent concurrent sending attempts (of different Nodes or applications) in the same Cell. ee6b9753367e8c81daad967bde4dcb3ffe19a09f 0 142 255 154 2013-12-22T20:23:12Z Oliver 1 wikitext text/x-wiki The arrangement of [[hardware element]] and/or [[software element]]s in a system. b16c42dd5bf8fa11cdd1f26063eedec3debaf192 0 206 239 2013-12-22T20:24:00Z Oliver 1 Redirected page to [[FlexRay Slot Number]] wikitext text/x-wiki #REDIRECT [[FlexRay Slot Number]] 18ed1c4de8907019a9709c3447f628a74ae1e8ae 0 207 240 2013-12-22T20:24:23Z Oliver 1 Redirected page to [[Editing FlexRay Slot Number]] wikitext text/x-wiki #REDIRECT [[Editing FlexRay Slot Number]] 62a0c26fb5865dae3454ad9b44691591db49dd40 0 208 241 2013-12-22T20:24:25Z Oliver 1 Created page with "An unequivocal number of a [[FlexRay Slot]], ranging from 1 to a configurable maximum number ≤ 2047. Synonym: “FlexRay Slot Identifier”, “FlexRay Slot ID”" wikitext text/x-wiki An unequivocal number of a [[FlexRay Slot]], ranging from 1 to a configurable maximum number ≤ 2047. Synonym: “FlexRay Slot Identifier”, “FlexRay Slot ID” 09dbfc130fa596ab6c881a283e5bab5cc7c12c20 0 209 242 2013-12-22T20:25:08Z Oliver 1 Created page with "A device that allows information to be transferred from one [[Physical Communication Link]] to one or more other Physical Communication Links. A star duplicates information pr..." wikitext text/x-wiki A device that allows information to be transferred from one [[Physical Communication Link]] to one or more other Physical Communication Links. A star duplicates information present on one of its links to the other links connected to the star. A star can be either passive or active. b65fbc3ff2be5c3272e20095c684dba18a0813a4 0 221 256 2013-12-22T20:25:09Z Oliver 1 Redirected page to [[Hardware Element]] wikitext text/x-wiki #REDIRECT [[Hardware Element]] f5d897bbc8a27bdb8a6dfad0bc55dfa35a018bbb 0 222 257 2013-12-22T20:25:11Z Oliver 1 Created page with "The HW Element is the main describing element of an [[ECU]]. It provides [[HW port]]s for being interconnected among each others. A generic HW Element specifies definitions va..." wikitext text/x-wiki The HW Element is the main describing element of an [[ECU]]. It provides [[HW port]]s for being interconnected among each others. A generic HW Element specifies definitions valid for all specific HW Elements. A HW Element is the piece or a part of the piece to be described with the [[ECU Resource Template]]. It uses other [[element]]s as [[primitive]]: This means HW elements can be nested (trough HW Containers, a hierarchical structure of HW Elements). At the lowest level a HW Element only uses primitives. c618c50f0fd27f3021dc46691489fb45d8ade4d6 0 210 243 2013-12-22T20:25:30Z Oliver 1 Redirected page to [[FlexRay Star]] wikitext text/x-wiki #REDIRECT [[FlexRay Star]] 5f8554ad5ce37073f5f5497e0f5f1cfcc9372345 0 223 258 2013-12-22T20:25:40Z Oliver 1 Redirected page to [[Hardware Interrupt]] wikitext text/x-wiki #REDIRECT [[Hardware Interrupt]] 11ae849890a570f7d636a5a50949cc17280592af 0 211 244 2013-12-22T20:26:11Z Oliver 1 Redirected page to [[FlexRay Star]] wikitext text/x-wiki #REDIRECT [[FlexRay Star]] 5f8554ad5ce37073f5f5497e0f5f1cfcc9372345 0 224 259 2013-12-22T20:26:35Z Oliver 1 Created page with "Interrupt triggered by [[HW event]]. There are two sorts of HW events -Processor-intern: events as for example division by zero, arithmetical overflow, non-implemented instruc..." wikitext text/x-wiki Interrupt triggered by [[HW event]]. There are two sorts of HW events -Processor-intern: events as for example division by zero, arithmetical overflow, non-implemented instruction -Processor-extern: events as for example response of peripheral device (e.g. [[PWM]]), memory error, timer 6b41f6978e27d1ec05b4309f0452a8e2ef4d0464 0 212 245 2013-12-22T20:26:46Z Oliver 1 Created page with "[[Data unit]] according to the data link protocol specifying the arrangement and meaning of bits or bit fields in the sequence of transfer across the transfer medium." wikitext text/x-wiki [[Data unit]] according to the data link protocol specifying the arrangement and meaning of bits or bit fields in the sequence of transfer across the transfer medium. 025138b34bb7c033956541ed94a03c2ec398e13c 0 225 260 2013-12-22T20:26:57Z Oliver 1 Redirected page to [[Hardware Port]] wikitext text/x-wiki #REDIRECT [[Hardware Port]] 509a6dab63c10f75dfb3b49ba34f7d7aab859ef1 0 213 246 2013-12-22T20:27:15Z Oliver 1 Created page with "A [[PDU]] that fits into 1 [[frame]] instance. e.g. it does not need to be fragmented across more than 1 frame for transmission over a network." wikitext text/x-wiki A [[PDU]] that fits into 1 [[frame]] instance. e.g. it does not need to be fragmented across more than 1 frame for transmission over a network. ca79e6cdd7013de2222604bc4e8f8a212008477f 0 226 261 2013-12-22T20:27:43Z Oliver 1 Created page with "The HW port exposes functionality to the exterior of the [[HW element]]. HW elements can be connected via [[HW Connection]]s. It defines a connection [[Endpoint]] for the HW E..." wikitext text/x-wiki The HW port exposes functionality to the exterior of the [[HW element]]. HW elements can be connected via [[HW Connection]]s. It defines a connection [[Endpoint]] for the HW Element. HW elements provide HW ports for being interconnected among each others. Each HW port has a name which is unique within the HW element it is located in. e049afb59193ce4e051fa9125b247db1805efa58 0 227 262 2013-12-22T20:30:09Z Oliver 1 Redirected page to [[PDU]] wikitext text/x-wiki #REDIRECT [[PDU]] 58d06faa214c8dfeac8e419a2dd450a733e80267 0 51 263 54 2013-12-22T20:30:11Z Oliver 1 wikitext text/x-wiki Interaction Layer [[PDU|Protocol Data Unit]]. Collection of [[message]]s for transfer between nodes in a [[network]]. At the sending node the [[Interaction Layer]] (IL) is responsible for packing messages into an I-PDU and then sending it to the [[Data Link Layer]] (DLL) for transmission. At the receiving node the DLL passes each I-PDU to the IL which then unpacks the messages sending their contents to the application. 93cec166a03bf1e8c54fd674586b19d96f3e7b8a 0 228 264 2013-12-22T20:30:48Z Oliver 1 Redirected page to [[ICC1]] wikitext text/x-wiki #REDIRECT [[ICC1]] e45cf61339902ba66373339eb3c00200acb04bd6 0 229 265 2013-12-22T20:31:28Z Oliver 1 Created page with "An ICC1 cluster offers a [[software-component interface]] (SW-CI) and/ or an [[AUTOSAR network interface]] (NWI). The SW-CI and NWI of an ICC1 cluster provide the functional b..." wikitext text/x-wiki An ICC1 cluster offers a [[software-component interface]] (SW-CI) and/ or an [[AUTOSAR network interface]] (NWI). The SW-CI and NWI of an ICC1 cluster provide the functional behavior as specified in the AUTOSAR specifications on [[ICC3]] level. fcec6bb64606fe599cd93ce7b43e005b1a570b1d 266 265 2013-12-22T20:33:02Z Oliver 1 wikitext text/x-wiki An ICC1 cluster offers a [[software-component interface]] (SW-CI) and/ or an [[AUTOSAR network interface]] (NWI). The SW-CI and NWI of an ICC1 cluster provide the functional behavior as specified in the AUTOSAR specifications on [[ICC3]] level. In an ICC1 cluster the basic software is regarded as a black box. It allows legacy platforms to migrate to AUTOSAR: - to be integrated into an AUTOSAR network - to support [[SW-C]]s. The features of an ICC1 cluster can be a subset of the ICC3 features (e.g. [[FlexRay]] not used). This has to be indicated in the [[Implementation Conformance Statement]] (ICS). The functionality represented in AUTOSAR by the [[RTE]] must be a part of any ICC1 cluster that provides an SW-CI. Typically an ICC1 cluster - is not structured into Basic Software ([[BSW]]) modules (ICC3) or BSW module clusters ([[ICC2]]) - has a proprietary internal structure and might consist of legacy/proprietary or highly optimized code. An ICC1 cluster shall provide an interface to the [[boot loader]]. ICC1 shall support SW-C compatible configuration for SW-CI and AUTOSAR Network compatible Configuration for NWI. ddca542feaac1c3683774fd676e20fa269a78b5e 0 230 267 2013-12-22T20:33:28Z Oliver 1 Redirected page to [[ICC2]] wikitext text/x-wiki #REDIRECT [[ICC2]] ef8d93fd5d6d74d57856484141b139a0571f3cb9 0 231 268 2013-12-22T20:35:06Z Oliver 1 Created page with "ICC2 clusters logically related [[ICC3]] Basic Software ([[BSW]]) modules (2… N modules). The number of Cluster Features in an ICC2 cluster is a subset of the union of the n..." wikitext text/x-wiki ICC2 clusters logically related [[ICC3]] Basic Software ([[BSW]]) modules (2… N modules). The number of Cluster Features in an ICC2 cluster is a subset of the union of the number of features of the clustered ICC3 modules. Each ICC2 cluster presents a subset of the clustered ICC3 module’s interfaces. ICC2 cluster provides the functional behavior as specified in the AUTOSAR specifications on ICC3 level. ICC2 cluster have a proprietary internal structure and might consist of proprietary or highly optimized code. ICC2 shall support AUTOSAR ECU Configuration description as an input for the Cluster Configuration It shall be possible to combine ICC2 Clusters and ICC3 Modules in a BSW Architecture. [[Application interface Conformance]] (above [[RTE]], [[software-component interface]], [[SW-CI]]) and [[Bus Conformance]] (AUTOSAR network interface, [[NWI]]) must be testable for a BSW which contain one or more ICC2 clusters. afe702a35295fba24a61951736d650bb5e3985ba 0 232 269 2013-12-22T20:35:51Z Oliver 1 Redirected page to [[ICC3]] wikitext text/x-wiki #REDIRECT [[ICC3]] c0754a33773297a3638377730d768647e20d3898 0 233 270 2013-12-22T20:36:56Z Oliver 1 Created page with "For ICC3 the AUTOSAR [[BSW]] consists of [[BSW modules]] as defined in the [[Basic Software Module List]], including the [[RTE]]. ICC3 is the highest level of granularity. All..." wikitext text/x-wiki For ICC3 the AUTOSAR [[BSW]] consists of [[BSW modules]] as defined in the [[Basic Software Module List]], including the [[RTE]]. ICC3 is the highest level of granularity. All [[Basic Software module]]s as defined in the BSW module list including the RTE, must comply with the defined interfaces and functionality as specified in their respective [[Software specification document]] (SWS). f737fbc35a0180a0301aa32b5c93ca236f7a28de 0 234 271 2013-12-22T20:37:32Z Oliver 1 Redirected page to [[BSWM]] wikitext text/x-wiki #REDIRECT [[BSWM]] 78ff659587ada34c2f379b873e08740d6a94487a 0 235 272 2013-12-22T20:38:38Z Oliver 1 Redirected page to [[Implementation Conformance Statement]] wikitext text/x-wiki #REDIRECT [[Implementation Conformance Statement]] 4f6b83c95823d508c475dd67621c1b0cec22c2e1 0 236 273 2013-12-22T20:40:12Z Oliver 1 Created page with "Implementation Conformance Statement (ICS) describes the actual implementation of a [[BSW module]] or a [[BSW cluster]] in terms of (1) the actually supported values or value ..." wikitext text/x-wiki Implementation Conformance Statement (ICS) describes the actual implementation of a [[BSW module]] or a [[BSW cluster]] in terms of (1) the actually supported values or value ranges of parameters that enable the configuration of the functionality of a module/cluster implementation and (2) the signatures of the operations actually provided and required at the interface of a module/cluster implementation (1) An [[SWS]] of a module/cluster specifies the configurable functionality and configurable operations of all SWS-conformant module/cluster implementations (BSW implementations). The ICS restricts the generally configurable functionality and operations according to what a concrete module/cluster actually implements according to the specification (SWS). (2) The ICS is used to derive values of configuration parameters (CP) valid for the given implementation of a module/cluster and, e.g., to select and parameterize conformance test suites. (3) A [[BSW implementation]] can consist of variable parts, i.e., operations and functionality. A BSW implementation can be adjusted with [[CP]]s within a certain range of permitted parameter values. An ICS describes which parts a BSW implementation actually supports and to what extend. (4) For any given CP : a. The absolute range is limited by the type of the CP. b. The permitted range is limited by the SWS. c. The actual range is limited by the implementation of the BSW module or BSW cluster. A test suite or the integration of the BSW module or BSW cluster into a target platform limits the actual range to a single value. 864219e3a4866ccbd92cd38a91959c2966c246d9 0 237 274 2013-12-22T20:40:37Z Oliver 1 Created page with "Service primitive defined in the ISO/OSI Reference Model (ISO 7498). With the service primitive 'indication' a service provider informs a service user about the occurrence of ..." wikitext text/x-wiki Service primitive defined in the ISO/OSI Reference Model (ISO 7498). With the service primitive 'indication' a service provider informs a service user about the occurrence of either an internal event or a service request issued by another service user. 2dabbb5e24331dde3f12846b2959355a6e8416d0 275 274 2013-12-22T20:41:00Z Oliver 1 wikitext text/x-wiki Service primitive defined in the ISO/OSI Reference Model (ISO 7498). With the service primitive 'indication' a service provider informs a service user about the occurrence of either an internal event or a service request issued by another service user. An indication is e.g. a specific notification generated by the [[OSEK]] underlying layer to inform about a [[Message Reception Error]]. 73b0d2dc8db0506377b62ab7a617930034ecebc4 0 238 276 2013-12-22T20:41:24Z Oliver 1 Created page with "The progressive assembling of [[system component]]s into the whole [[system]]." wikitext text/x-wiki The progressive assembling of [[system component]]s into the whole [[system]]. f5da270355bec49754399284cb5028325c49e18c 0 239 277 2013-12-22T20:41:54Z Oliver 1 Created page with "Code that the Integrator needs to add to an AUTOSAR System, to adapt non-standardized functionalities. Examples are Callouts of the [[ECU State Manager]] and Callbacks of vari..." wikitext text/x-wiki Code that the Integrator needs to add to an AUTOSAR System, to adapt non-standardized functionalities. Examples are Callouts of the [[ECU State Manager]] and Callbacks of various other [[BSW Module]]s. 5958844221bfbe4d352778fb1980fac578640132 0 240 278 2013-12-22T20:43:03Z Oliver 1 Created page with "A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and oth..." wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. In AUTOSAR the interface has specific meanings: [[Standardized AUTOSAR Interface]] and [[Standardized Interface]]. 891406b03ee3e0be79df24b1a549441359ec6ea7 0 241 279 2013-12-22T20:43:44Z Oliver 1 Created page with "Event that enforces the processor to change its state. This interruption causes the normal sequence of instructions to be stopped. Once an interrupt occurred, the running soft..." wikitext text/x-wiki Event that enforces the processor to change its state. This interruption causes the normal sequence of instructions to be stopped. Once an interrupt occurred, the running software entity is suspended and an [[interrupt service routine|ISR]] (the one dedicated to this interrupt) is called. 5001902b149eeace79cbf675dad28f47bf8581d1 281 279 2013-12-22T20:44:47Z Oliver 1 wikitext text/x-wiki Event that enforces the processor to change its state. This interruption causes the normal sequence of instructions to be stopped. Once an interrupt occurred, the running software entity is suspended and an [[interrupt service routine]] (the one dedicated to this interrupt) is called. 7a0ddbeb3a69a6ffd84595342592a751baf4eddb 0 242 280 2013-12-22T20:44:31Z Oliver 1 Redirected page to [[ISR]] wikitext text/x-wiki #REDIRECT [[ISR]] 9e850b66ac755e724692b399cfeaf99dcfe59286 0 243 282 2013-12-22T20:45:25Z Oliver 1 Created page with "An [[interrupt]] frame is the code which handles the entering/leaving of (C written) [[interrupt service routine]]s. This code is microcontroller specific and often written in..." wikitext text/x-wiki An [[interrupt]] frame is the code which handles the entering/leaving of (C written) [[interrupt service routine]]s. This code is microcontroller specific and often written in assembly language. Interrupt frames are typically generated by the OS generation tool. f2e8ae4136cd886d623adf1f3526ec13c3e20735 0 244 283 2013-12-22T20:46:12Z Oliver 1 Created page with "In the case of a [[Category 2 interrupt]], the [[ISR]] is synonymous with Interrupt Handler. In the case of [[Category 1 interrupt]] the Interrupt Handler is the function call..." wikitext text/x-wiki In the case of a [[Category 2 interrupt]], the [[ISR]] is synonymous with Interrupt Handler. In the case of [[Category 1 interrupt]] the Interrupt Handler is the function called by the [[hardware interrupt vector]]. In both cases the Interrupt handler is the user code that is normally a part of the [[BSW module]]. So the Interrupt Handler is a user level piece of code. 60ae0ba510b7132346d1c1ac0f20681a1b80f399 0 245 284 2013-12-22T20:46:44Z Oliver 1 Created page with "This is the [[MCU]] logic that controls all [[interrupt]]s for all devices. This is normally controlled by the [[OS]]." wikitext text/x-wiki This is the [[MCU]] logic that controls all [[interrupt]]s for all devices. This is normally controlled by the [[OS]]. c1cc79e8060b1e7a73643d13f6939df3fd7b3fd0 0 52 285 55 2013-12-22T20:47:17Z Oliver 1 wikitext text/x-wiki Interrupt Service Routine is a [[software routine]] called in case of an [[interrupt]]. 58003e56766915947fc3e5685ca98cd502a2dabd 0 246 286 2013-12-22T20:47:50Z Oliver 1 Created page with "An [[interrupt]] vector table is a table of interrupt vectors that associates the [[interrupt service routine]]s with the corresponding interrupt request (typically by an arra..." wikitext text/x-wiki An [[interrupt]] vector table is a table of interrupt vectors that associates the [[interrupt service routine]]s with the corresponding interrupt request (typically by an array of jumps or similar mechanisms). 0d76b5bf53b6460bbc26562aeb8e3d06a5bc42e6 0 247 287 2013-12-22T20:50:32Z Oliver 1 Created page with "For a [[signal]] in a [[PDU]] an optional invalid flag can be added to the [[PDU payload layout]]. This flag indicates the validity of other signals in the payload. In case th..." wikitext text/x-wiki For a [[signal]] in a [[PDU]] an optional invalid flag can be added to the [[PDU payload layout]]. This flag indicates the validity of other signals in the payload. In case the invalid flag of a signal is set to true in a [[PDU instance]], the respective signal in the payload of the PDU instance does not contain a valid signal value. This mechanism may be used in gateways to indicate that parts of an PDU do not contain valid data. d0ad95c704dbc78f72a414a1ab2d088ea5c4bff0 0 248 288 2013-12-22T20:51:22Z Oliver 1 Created page with "For a [[signal]] in a [[PDU]] an optional invalid value can be defined. The invalid value is element of the signal value range that can be represented and transported by the s..." wikitext text/x-wiki For a [[signal]] in a [[PDU]] an optional invalid value can be defined. The invalid value is element of the signal value range that can be represented and transported by the signal. The invalid value is the value that is used in all situations where the receiver should be notified that the value in a signal is not valid. ca25241c4d59b5b5325321ed36db07792f2f373a 0 249 289 2013-12-22T20:52:06Z Oliver 1 Created page with "The [[configuration]] of the [[SW module]] is done during [[link time]]. The [[object code]] of the SW modules receives parts of its configuration from another object code fil..." wikitext text/x-wiki The [[configuration]] of the [[SW module]] is done during [[link time]]. The [[object code]] of the SW modules receives parts of its configuration from another object code file or it is defined by [[linker option]]s. 44d67ac615e10d8b0ddbeb1debff883b5a4499cc 0 250 290 2013-12-22T20:52:52Z Oliver 1 Created page with "Mapping designates the distribution of [[element]]s in the [[logical view]] to elements in the [[physical view]]. In general several entities may be allocated to one [[contain..." wikitext text/x-wiki Mapping designates the distribution of [[element]]s in the [[logical view]] to elements in the [[physical view]]. In general several entities may be allocated to one [[container]] but an [[entity]] may be allocated to only one container. 8ce446d70494f6bac974869faadb5cb7d1194ddb 0 251 291 2013-12-22T20:54:17Z Oliver 1 Created page with "The [[MCAL]] signal is the software representation of the [[conditioned signal]]. It is provided by the microcontroller abstraction layer (MCAL) and is further processed by th..." wikitext text/x-wiki The [[MCAL]] signal is the software representation of the [[conditioned signal]]. It is provided by the microcontroller abstraction layer (MCAL) and is further processed by the [[ECU abstraction]]. The processing unit is accessing the Conditioned Signal through some peripheral device that typically digitizes the Conditioned Signal into a software representation. The transformation from the Conditioned Signal to the MCAL Signal has to take the digitalization error into account in order to provide information about the quality loss between the [[Technical Signal]] and the MCAL Signal. 54e646a605e638035772b7430e858a3f51a6130d 0 252 292 2013-12-22T21:04:34Z Oliver 1 Created page with "A Model of a Model, in other words a Model on [[M2]]." wikitext text/x-wiki A Model of a Model, in other words a Model on [[M2]]. 7104de23d7c90ff333b0c862254a1ac4a7c0e96b 0 115 293 121 2013-12-22T21:04:58Z Oliver 1 wikitext text/x-wiki In AUTOSAR, the possible partitioning of models is marked in the [[meta-model]] by <<atpSplitable>>. One partial model is represented in an [[AUTOSAR XML description]] by one file. The partial model does not need to fulfill all semantic constraints applicable to an [[AUTOSAR model]]. 9b658bc3c7e3d2e502f91b8956f585b326bd9bdd 0 253 294 2013-12-22T21:05:11Z Oliver 1 Redirected page to [[Meta Model]] wikitext text/x-wiki #REDIRECT [[Meta Model]] b845f5e128879cae975d691fc0eeab87c900a52c 0 254 295 2013-12-22T21:05:25Z Oliver 1 Created page with "Metadata is data about data." wikitext text/x-wiki Metadata is data about data. a5b2af2d8bd7295117d4f973fa15247e3378cf91 0 255 296 2013-12-22T21:06:01Z Oliver 1 Redirected page to [[MCAL]] wikitext text/x-wiki #REDIRECT [[MCAL]] 351e6f05a190681982f9049e278927d3e06541b5 0 256 297 2013-12-22T21:06:19Z Oliver 1 Created page with "#RECIREDT [[MCAL]]" wikitext text/x-wiki #RECIREDT [[MCAL]] 4fd3c7294a7ae926e2f24fd3160a9f37afc18f8d 0 59 298 62 2013-12-22T21:07:51Z Oliver 1 wikitext text/x-wiki Microcontroller Abstraction Layer (MCAL) Software layer containing [[driver]]s to enable the access of on-chip peripheral devices of a microcontroller and off-chip memory mapped peripheral devices by a defined [[API]]. Task: make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer is the lowest software layer of the [[Basic Software]]. The Microcontroller Abstraction Layer consists of the following parts:  I/O Drivers  Communication Drivers  Memory Drivers  Microcontroller Drivers Properties:  Implementation: [[uC]] dependent  Upper Interface (API): standardize-able and uC independent 233610a8612f37de9782ee7c218d471695ea620a 0 257 299 2013-12-22T21:09:12Z Oliver 1 Created page with "A Mode is a certain set of [[state]]s of the various [[state machine]]s that are running in the vehicle that are relevant to a particular entity, e.g. a [[SW-C]], a [[BSW modu..." wikitext text/x-wiki A Mode is a certain set of [[state]]s of the various [[state machine]]s that are running in the vehicle that are relevant to a particular entity, e.g. a [[SW-C]], a [[BSW module]], an [[application]] or a whole vehicle. In its [[lifetime]], an entity changes between a set of [[mutually exclusive]] Modes. These changes are triggered by [[environmental data]], e.g. signal reception, operation invocation. 8368441cbc9c3d16d680dffdb5d1e805378c469c 0 258 300 2013-12-22T21:09:30Z Oliver 1 Created page with "An M1 - Model, it is an instance of the [[Meta Model]]." wikitext text/x-wiki An M1 - Model, it is an instance of the [[Meta Model]]. 3db5655dd4523f91a1ef8364f60faca789687d3c 0 259 301 2013-12-22T21:10:46Z Oliver 1 Created page with "A consistent sequence of digital data versus time which is suited as input for devices which transfer these data into a continuous visible or audible impression to humans. Whe..." wikitext text/x-wiki A consistent sequence of digital data versus time which is suited as input for devices which transfer these data into a continuous visible or audible impression to humans. When transferred over a [[physical link]], multimedia stream data typically are produced at the same rate (by the data source), as they are consumed (by the data sinks). A multimedia stream usually follows a certain standard (e.g. MPEG-x). When transferred over a physical link, a multimedia stream needs a certain minimum [[bandwidth]] (in terms of bits/second) in order to allow continuous impressions. A multimedia stream in a car typically exists for several seconds (a warning signal, a navigation hint) up to several hours (a video film, a phone call, playing a radio program). Resources (e.g. bus system channels) needed by the stream have to be allocated continuously over this lifetime (this is a difference to e.g. file transfer, which may be split into several chunks of data). The source of a multimedia stream typically is a specialized device and/or software program (a tuner, a microphone, a text-to-speech engine, etc.). The same holds for the sinks (an audio amplifier or mixer, a voice recognition software, an MPEG decoder, etc.). 14f742344e8d94287139653dbec41452bfa26c1d 0 260 302 2013-12-22T21:11:47Z Oliver 1 Created page with "A [[SW module]] has more than one alternative [[configuration]] ([[parameter]]) set, which can be selected according to external requirements. The set can ONLY be selected dur..." wikitext text/x-wiki A [[SW module]] has more than one alternative [[configuration]] ([[parameter]]) set, which can be selected according to external requirements. The set can ONLY be selected during [[start-up]] and it is not allowed to switch the set during [[runtime]]. Multiple configuration sets reside in the [[ECU]] [[non-volatile memory]] at the same time, the active configuration is selected at the start-up of the ECU. Only [[BSW module]]s can have multiple configuration sets. 5ae3c0ca9637e87115ec6a4e94aeeefbea6f5866 0 262 304 2013-12-22T21:12:45Z Oliver 1 Created page with "A multiplexed [[PDU]] is a PDU with a configurable number of different [[payload layout]]s. Each instance of a multiplexed PDU has a distinct layout. The set of possible layou..." wikitext text/x-wiki A multiplexed [[PDU]] is a PDU with a configurable number of different [[payload layout]]s. Each instance of a multiplexed PDU has a distinct layout. The set of possible layouts is statically defined. A selector signal defines which layout is used in a PDU instance. The selector signal must reside at the same position in all layouts. Each layout is identified by a unique selector value. The length of each instance of a multiplexed PDU is fixed. 264e6a80f669e73765029250da67f9c1cd9dbb02 0 263 305 2013-12-22T21:13:27Z Oliver 1 Redirected page to [[Network Interface]] wikitext text/x-wiki #REDIRECT [[Network Interface]] 83e3411a9dc0319f045d5b958e07208b2fae0f64 0 264 306 2013-12-22T21:16:07Z Oliver 1 Created page with "A Network Interface is the sum of all [[interface]]s offered by the [[Basic Software]] towards its connected [[network]]. The interface that the Basic Software shares via the ..." wikitext text/x-wiki A Network Interface is the sum of all [[interface]]s offered by the [[Basic Software]] towards its connected [[network]]. The interface that the Basic Software shares via the [[communication line]]s with other systems that behave like AUTOSAR ECUs in order to - allow distributed [[SW-C]]s to exchange [[inter-ECU signal]]s and to - operate the communication lines (the network) is called Network Interface. A Network Interface (NWI) denotes the interface between the Basic Software and the [[physical network]] (OSI Layer 0) to which the ECU executing the Basic Software is connected to (e.g. [[CAN]], [[LIN]], [[FlexRay]]). The NWI therefore transports [[network data packet]]s between the Basic Software and the physical network. The interfaces included within the term NWI are: - [[Logical interface]]s, including o Network Management o Data Management o Data transmission/reception The interfaces excluded from the term NWI are: - The physical network interface (CAN, FlexRay etc.). Note that, while attention must be given to the physical form of the network, since it is not formally specified by AUTOSAR, it cannot be considered a part of the conformance test of an AUTOSAR cluster. The NWI provided by a given ECU supports the transfer of data to and from the ECU, and management of the network. For the purposes of this definition, the Basic Software can be designed according to [[ICC1]], [[ICC2]] or [[ICC3]]. 6823add8e7cf05df28b9e2c98948c85944495aa5 0 265 307 2013-12-22T21:17:30Z Oliver 1 Created page with "A [[Network Management]} Coordination [[Cluster]] is a discrete set of [[NM Channel]]s on which [[shutdown]] is coordinated. The NM Coordinator will keep all presently awake N..." wikitext text/x-wiki A [[Network Management]} Coordination [[Cluster]] is a discrete set of [[NM Channel]]s on which [[shutdown]] is coordinated. The NM Coordinator will keep all presently awake NM Channels of an NM Coordination Cluster awake until it is possible to coordinate [[network sleep]] on all the awake channels. 3606da29eed34142cb0fd0f27bc7107fd773c8d0 0 266 308 2013-12-22T21:18:48Z Oliver 1 Created page with "A [[Network Management]] Coordinator is a functionality of the Generic NM Interface which allows coordination of network [[sleep]] for multiple [[NM Channel]]s. Depending on c..." wikitext text/x-wiki A [[Network Management]] Coordinator is a functionality of the Generic NM Interface which allows coordination of network [[sleep]] for multiple [[NM Channel]]s. Depending on configuration, different level of [[synchronous network sleep]] can be achieved. The NM Coordinator is using a generic coordination algorithm which, by means of individually configured timeout and synchronization indications can coordinate a synchronized [[shutdown]] of multiple NM Channels. bb8d0c12cb7b1bf68d9e5588d1fcf06d1ddcf1a9 0 267 309 2013-12-22T21:23:47Z Oliver 1 Created page with "Informing a [[software entity]] about a state change of a [[hardware entity]] and/or software entity which has occurred. The informing about a [[state change]] can be done by ..." wikitext text/x-wiki Informing a [[software entity]] about a state change of a [[hardware entity]] and/or software entity which has occurred. The informing about a [[state change]] can be done by an activation of a software part or by setting a [[flag]]. 89b8e98befd7876adf2ab8efba224ef313e4e5e7 0 268 310 2013-12-22T21:25:11Z Oliver 1 Created page with "A block of software including [[task]]s, [[interrupt]]s, [[hook]]s and [[user service]]s that form a cohesive [[functional unit]]. Trusted: An OS-Application that is executed ..." wikitext text/x-wiki A block of software including [[task]]s, [[interrupt]]s, [[hook]]s and [[user service]]s that form a cohesive [[functional unit]]. Trusted: An OS-Application that is executed in [[privileged mode]] and has unrestricted access to the [[API]] and [[hardware resource]]s. Non-trusted: An OS-Application that is executed in [[non-privileged mode]] has restricted access to the API and hardware resources. b6f684831917e836da97656f9570d3e32f53d3d1 0 269 311 2013-12-22T21:25:37Z Oliver 1 Created page with "This is a part of a model which is intended to be persisted in one particular [[artifact]]." wikitext text/x-wiki This is a part of a model which is intended to be persisted in one particular [[artifact]]. 6ea866966080b2665dc1ba45907c926d9db394d2 0 115 312 293 2013-12-22T21:26:02Z Oliver 1 wikitext text/x-wiki In AUTOSAR, the possible [[partitioning]] of models is marked in the [[meta-model]] by <<atpSplitable>>. One partial model is represented in an [[AUTOSAR XML description]] by one file. The partial model does not need to fulfill all semantic constraints applicable to an [[AUTOSAR model]]. ffa52e85d36597958ea68d2c586e65349a75b18d 0 270 313 2013-12-22T21:37:36Z Oliver 1 Created page with "[[Decomposition]], the separation of the whole [[system]] into [[functional unit]]s and further into [[software component]]s. Partitioning has to be done before the [[mapping]..." wikitext text/x-wiki [[Decomposition]], the separation of the whole [[system]] into [[functional unit]]s and further into [[software component]]s. Partitioning has to be done before the [[mapping]] in order to identify the components that are to be mapped. 788d8717d98c8a7d1f5d088d059fc4af4ea54d74 0 271 314 2013-12-22T21:38:03Z Oliver 1 Redirected page to [[PCI]] wikitext text/x-wiki #REDIRECT [[PCI]] 95db2a4611aeecfd1a3242def92653b92eafda43 0 77 315 80 2013-12-22T21:38:41Z Oliver 1 wikitext text/x-wiki PCI is the abbreviation of “Protocol Control Information”. This Information is needed to pass a [[SDU]] from one [[instance]] of a specific protocol layer to another instance. E.g. it contains source and target information. The PCI is added by a [[protocol layer]] on the transmission side and is removed again on the receiving side. d1802d1d27320c3f84bfdd396f196339a9924770 0 70 316 73 2013-12-22T21:39:40Z Oliver 1 Redirected page to [[Protocol Data Unit]] wikitext text/x-wiki #REDIRECT [[Protocol Data Unit]] 520fc5c7c7b66fc7a6084cb7d2b2f9948c45a952 0 227 317 262 2013-12-22T21:39:58Z Oliver 1 wikitext text/x-wiki PDU is the abbreviation of “Protocol Data Unit”. The PDU contains [[SDU]] and [[PCI]]. 83ac91247aa5e8ff49d9831e785fdd74723ce579 318 317 2013-12-22T21:40:23Z Oliver 1 wikitext text/x-wiki PDU is the abbreviation of “Protocol Data Unit”. The PDU contains [[SDU]] and [[PCI]]. On the transmission side the PDU is passed from the upper layer to the lower layer, which interprets this PDU as its SDU. c5b21cc3d76a281ea49ae5abe0853a0ecb34a253 0 272 319 2013-12-22T21:40:43Z Oliver 1 Created page with "Maximum time between the receptions of two instances of one [[PDU]] is exceeded." wikitext text/x-wiki Maximum time between the receptions of two instances of one [[PDU]] is exceeded. ad30cd930a4816dc622ae7b9744c75f0a6352f37 320 319 2013-12-22T21:41:00Z Oliver 1 wikitext text/x-wiki Maximum time between the receptions of two instances of one [[PDU]] is exceeded. This timeout indicates that the last reception of a [[PDU instance]] is too long in the past. As a consequence it can be concluded that the data in the last PDU instance is outdated. b102267b26b93d0f5f7ca804a043f12e9b52a4f2 0 273 321 2013-12-22T21:42:27Z Oliver 1 Created page with "Hardware devices integrated in micro-controller architecture to interact with the environment." wikitext text/x-wiki Hardware devices integrated in micro-controller architecture to interact with the environment. ffc3a27f31521986f6ace3552d5c44d33fea80b4 0 274 322 2013-12-22T21:42:49Z Oliver 1 Created page with "User-specific and memorized adjustment of [[SW]] data or selection of functional alternatives." wikitext text/x-wiki User-specific and memorized adjustment of [[SW]] data or selection of functional alternatives. 7c851c0ec9c4beff9b32d301a74820656c2e4b47 0 275 323 2013-12-22T21:43:52Z Oliver 1 Created page with "A port belongs to a [[software component]] and is the interaction point between the [[component]] and other components. The interaction between specific ports of specific comp..." wikitext text/x-wiki A port belongs to a [[software component]] and is the interaction point between the [[component]] and other components. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[p-port]] or an [[r-port]]. 079fb126becf2d5ab6a9659788f21bb21e65350d 0 276 324 2013-12-22T21:45:03Z Oliver 1 Created page with "A Port Interface characterizes the information provided or required by a [[port]] of a [[software component]]. A Port Interface is either a [[Client-Server Interface]] in case..." wikitext text/x-wiki A Port Interface characterizes the information provided or required by a [[port]] of a [[software component]]. A Port Interface is either a [[Client-Server Interface]] in case [[client-server communication]] is chosen or a [[sender-receiver Interface]] in case [[sender-receiver communication]] is used. d704dc14d5472cb12102af652feaf192bcce7862 0 277 325 2013-12-22T21:46:13Z Oliver 1 Created page with "The [[configuration]] of the [[SW module]] is possible after building the SW module. The SW may either receive [[element]]s of its configuration during the download of the com..." wikitext text/x-wiki The [[configuration]] of the [[SW module]] is possible after building the SW module. The SW may either receive [[element]]s of its configuration during the download of the complete [[ECU]] software resulting from the linkage of the code, or it may receive its configuration file that can be downloaded to the ECU separately, avoiding a re-compilation and re-build of the ECU [[SW module]]s. In order to make the post-build time re-configuration possible, the re-configurable elements shall be stored at a known position in the ECU storage area. 4fe0e0e6a2860cb63764f85e62038bb98e91c99b 0 278 326 2013-12-22T21:46:51Z Oliver 1 Created page with "The [[configuration]] of the [[SW module]] is done at source code level and will be effective after compile time. The source code contains all the [[ECU]] configuration data a..." wikitext text/x-wiki The [[configuration]] of the [[SW module]] is done at source code level and will be effective after compile time. The source code contains all the [[ECU]] configuration data and when compiled together, it produces the given [[SW]]. 11d7cf3b4b21eb6f109ce978065539e35964ffe5 0 279 327 2013-12-22T21:47:27Z Oliver 1 Redirected page to [[Private Interface]] wikitext text/x-wiki #REDIRECT [[Private Interface]] 42eecf928d3d4fd1c5eeabeefd6c5767a4535aba 0 280 328 2013-12-22T21:48:18Z Oliver 1 Created page with "A private interface is an [[interface]] within the [[Basic Software]] of AUTOSAR which is neither standardized nor defined within AUTOSAR. The goal of the private interface is..." wikitext text/x-wiki A private interface is an [[interface]] within the [[Basic Software]] of AUTOSAR which is neither standardized nor defined within AUTOSAR. The goal of the private interface is to enable a more efficient implementation of basic software modules. [[Basic software module]]s sharing a private interface have to be distributed as one package. This package has to behave exactly the same as separate modules would. It must provide the same standardized interfaces to the rest of the basic software and/or [[RTE]] as separate modules would. It has to be configured exactly the same as separate modules would be configured. 190a97937bd632202b32adbb218ae76ed5b48877 0 281 329 2013-12-22T21:48:42Z Oliver 1 Created page with "Probability of the occurrence of a [[failure]] in a [[system]] or [[functional unit]]." wikitext text/x-wiki Probability of the occurrence of a [[failure]] in a [[system]] or [[functional unit]]. d2a3d389a060915bfdc6c10fadf69131af5c4aa2 0 282 330 2013-12-22T21:49:19Z Oliver 1 Created page with "A simple statement that provides the actual [[parameter]]s for and invokes the execution of a [[procedure]] (software function). A [[synchronous communication]] mechanism can ..." wikitext text/x-wiki A simple statement that provides the actual [[parameter]]s for and invokes the execution of a [[procedure]] (software function). A [[synchronous communication]] mechanism can be implemented by a procedure call. 1ec3ff99226d44393a4783c3ebc4019b25019af8 0 283 331 2013-12-22T21:50:07Z Oliver 1 Created page with "An [[executable unit]] managed by an [[operating system scheduler]] that has its own [name space] and resources (including memory) protected against use from other processes. ..." wikitext text/x-wiki An [[executable unit]] managed by an [[operating system scheduler]] that has its own [name space] and resources (including memory) protected against use from other processes. A process consists of n [[Task]] (n>=1) 9078dcaf170c72791c4b3751fb70627764a93735 0 284 332 2013-12-22T21:50:29Z Oliver 1 Redirected page to [[Provide Port]] wikitext text/x-wiki #REDIRECT [[Provide Port]] e7c8161a7cbf5698923c5acf57b767959ffb1fcd 0 285 333 2013-12-22T21:51:21Z Oliver 1 Redirected page to [[Provide Port]] wikitext text/x-wiki #REDIRECT [[Provide Port]] e7c8161a7cbf5698923c5acf57b767959ffb1fcd 0 286 334 2013-12-22T21:51:24Z Oliver 1 Created page with "Specific [[Port]] providing [[data]] or providing a [[service]] of a [[server]]. The Provide Port is sometimes abbreviated as PPort or P-Port." wikitext text/x-wiki Specific [[Port]] providing [[data]] or providing a [[service]] of a [[server]]. The Provide Port is sometimes abbreviated as PPort or P-Port. d1c59ece513845460842f2e34eecc105184933aa 0 287 335 2013-12-22T21:51:58Z Oliver 1 Created page with "Operation to change the timing between two transmissions of the same [[PDU-Id]] on one [[physical network]]." wikitext text/x-wiki Operation to change the timing between two transmissions of the same [[PDU-Id]] on one [[physical network]]. da1b17df790a4019a562e0188cdd7c13f933cb2c 0 288 336 2013-12-22T21:52:39Z Oliver 1 Created page with "Existence of means in addition to the means that would be sufficient for an element to perform a required [[function]] or to represent information. Redundancy is used in ISO 2..." wikitext text/x-wiki Existence of means in addition to the means that would be sufficient for an element to perform a required [[function]] or to represent information. Redundancy is used in ISO 26262 with respect to achieving a [[safety goal]], a specified safety requirement, or representing safety-related information. 7e87df6a87fbc9bc5ac1a47d19be03fcbbe77361 0 289 337 2013-12-22T21:53:04Z Oliver 1 Created page with "Probability of a [[system]] or [[functional unit]] to perform as expected under specified conditions within a time interval." wikitext text/x-wiki Probability of a [[system]] or [[functional unit]] to perform as expected under specified conditions within a time interval. 367fe3be0169e3d79589160fd4f097bbacd583d1 0 290 338 2013-12-22T21:53:33Z Oliver 1 Created page with "Capability of a software part being executed on different [[hardware environment]]s without changing the code of the software part." wikitext text/x-wiki Capability of a software part being executed on different [[hardware environment]]s without changing the code of the software part. 95aaefc21ab7dd6059cb1e2b029ff636079aff6e 0 291 339 2013-12-22T21:54:38Z Oliver 1 Redirected page to [[Require Port]] wikitext text/x-wiki #REDIRECT [[Require Port]] 3e9aba3b4df167859513e9528b98ea3606ecee8e 0 292 340 2013-12-22T22:05:05Z Oliver 1 Redirected page to [[Require Port]] wikitext text/x-wiki #REDIRECT [[Require Port]] 3e9aba3b4df167859513e9528b98ea3606ecee8e 0 293 341 2013-12-22T22:09:56Z Oliver 1 Created page with "Specific [[Port]] requiring [[data]] or requiring a [[service]] of a [[server]]. The Require Port is sometimes abbreviated as RPort or R-Port." wikitext text/x-wiki Specific [[Port]] requiring [[data]] or requiring a [[service]] of a [[server]]. The Require Port is sometimes abbreviated as RPort or R-Port. 63262659c02f5b9429126b6c7731bdf238056c7b 0 294 342 2013-12-22T22:10:45Z Oliver 1 Created page with "A required property or quality of a design entity (e.g. [[SW component]] or [[system]]) is a property or quality which has to be fulfilled by the environment of this design en..." wikitext text/x-wiki A required property or quality of a design entity (e.g. [[SW component]] or [[system]]) is a property or quality which has to be fulfilled by the environment of this design entity. A property or quality can be required by a [[stakeholder]] (e.g. customer) or another [[design entity]]. d5bf25b781b31b559e31fc3e76e66a266b570fa2 0 295 343 2013-12-22T22:11:12Z Oliver 1 Created page with "The ratio of the number of bits, unit elements, or blocks incorrectly received and undetected, to the total number of bits, unit elements, characters, or blocks sent." wikitext text/x-wiki The ratio of the number of bits, unit elements, or blocks incorrectly received and undetected, to the total number of bits, unit elements, characters, or blocks sent. 7c873c8a57e67e4dcbc78a5d93ed466bd7de0fb4 0 296 344 2013-12-22T22:12:20Z Oliver 1 Created page with "A resource is a required but limited hardware entity of an [[ECU]], which in general can be accessed concurrently, but not simultaneously, by multiple [[software entity|softwa..." wikitext text/x-wiki A resource is a required but limited hardware entity of an [[ECU]], which in general can be accessed concurrently, but not simultaneously, by multiple [[software entity|software entities]]. The [[OSEK]] definition [OSEK BD] cannot be used, due to the specific usage in OSEK [[OS]]. 87cd7a2d9e44ae30446b0d4148f55ca04a0c6a92 0 297 345 2013-12-22T22:12:58Z Oliver 1 Created page with "Entity which controls the use of [[resource]]s. The main functionality of resource management is the control of simultaneous use of a single resource by several entities, e.g...." wikitext text/x-wiki Entity which controls the use of [[resource]]s. The main functionality of resource management is the control of simultaneous use of a single resource by several entities, e.g. scheduling of [[request]]s, multiple access protection. 22bd8dbd0f27a7183cb3ca2f5dc87e3303527a8d 0 97 346 100 2013-12-22T22:13:20Z Oliver 1 wikitext text/x-wiki Worst Case [[Response time]] 00f3e003fb70b9ddf5f6818f9a7781f210c194e6 0 298 347 2013-12-22T22:14:21Z Oliver 1 Redirected page to [[Response time]] wikitext text/x-wiki #REDIRECT [[Response time]] 6ba6bbf752cb80fe85720b8ea40b1efca76bffd7 0 299 348 2013-12-22T22:14:23Z Oliver 1 Created page with "Time between receiving a stimulus and delivering an appropriate response or reaction. The response time describes the time between a stimulus like e.g. the state change of har..." wikitext text/x-wiki Time between receiving a stimulus and delivering an appropriate response or reaction. The response time describes the time between a stimulus like e.g. the state change of hardware or [[software entity]] and the expected reaction of the [[system]] (e.g. response, actuator activation). Synonym: reaction time See also: [[execution time]], [[worst case execution time]] and [[worst case response time]]. 0d20954636981a981a016f79bc0d3dd1d0ced744 0 307 360 2013-12-22T22:24:27Z Oliver 1 Created page with "Defined [[system]] used for evaluation purposes. The application may be simplified for better understanding within the evaluation phase." wikitext text/x-wiki Defined [[system]] used for evaluation purposes. The application may be simplified for better understanding within the evaluation phase. a14edf6add8a4476bb4190395001d63ff6b7959b 0 308 361 2013-12-22T22:24:46Z Oliver 1 Created page with "The degree to which assets can be adapted to specific target environments for various defined measures." wikitext text/x-wiki The degree to which assets can be adapted to specific target environments for various defined measures. 071726dc348b1b6f7534d2cc4b1d2c3dcab363f6 0 309 362 2013-12-22T22:26:06Z Oliver 1 Created page with "The scheduler handles the scheduling of the [[task]]s/[[runnable entity|runnable entities]] according to the priority and scheduling policy (pre-defined or configurable). It h..." wikitext text/x-wiki The scheduler handles the scheduling of the [[task]]s/[[runnable entity|runnable entities]] according to the priority and scheduling policy (pre-defined or configurable). It has the responsibility to decide during [[run-time]] when which task can run on the [[CPU]] of the [[ECU]]. There are many strategies (priority-based, time-triggered, round-robbin, …) a scheduler can use, depending of the selected and/or implemented algorithms. 03686ccf99767743936417bc2e4c9c66a2ee1a77 0 300 349 2013-12-22T22:26:45Z Oliver 1 Created page with "Combination of the probability of occurrence of harm and the severity of that harm." wikitext text/x-wiki Combination of the probability of occurrence of harm and the severity of that harm. cc7e617138961f5c5f3b1bca1203c680f412425b 0 69 363 72 2013-12-22T22:26:48Z Oliver 1 Redirected page to [[Service Data Unit]] wikitext text/x-wiki #REDIRECT [[Service Data Unit]] 0820b3f7e52054cfe85ea8744db14475fdc591ac 0 301 350 2013-12-22T22:27:08Z Oliver 1 Created page with "Ability of a [[system]] or [[functional unit]] to perform as expected also under unexpected conditions." wikitext text/x-wiki Ability of a [[system]] or [[functional unit]] to perform as expected also under unexpected conditions. f8537442d3912973ffcdbe896345820a0a83d9b2 0 310 364 2013-12-22T22:27:13Z Oliver 1 Created page with "SDU is the abbreviation of “Service Data Unit”. It is the data passed by an upper layer, with the request to transmit the [[data]]. It is as well the data, which is extrac..." wikitext text/x-wiki SDU is the abbreviation of “Service Data Unit”. It is the data passed by an upper layer, with the request to transmit the [[data]]. It is as well the data, which is extracted after reception by the lower layer and passed to the upper layer. A SDU is part of a [[PDU]]. b78e615cc8eaa192339d57807a2908583f819eac 0 311 365 2013-12-22T22:27:32Z Oliver 1 Created page with "Protection of data, software entities or resources from accidental or malicious acts." wikitext text/x-wiki Protection of data, software entities or resources from accidental or malicious acts. 302f0e7c67f0cfef5bff15021690bfbe8deefc94 0 312 366 2013-12-22T22:28:29Z Oliver 1 Created page with "A communication pattern which offers asynchronous distribution of information where a [[sender]] communicates information to one or more [[receiver]]s, or a receiver receives ..." wikitext text/x-wiki A communication pattern which offers asynchronous distribution of information where a [[sender]] communicates information to one or more [[receiver]]s, or a receiver receives information from one or several senders. The process of sending data does not block the sender and the sender usually gets no response from the receivers. 17186a3b052b65f34dbd71780907d7cededb78bd 0 302 351 2013-12-22T22:28:32Z Oliver 1 Created page with "An RTE [[Event]] encompasses all possible situations that can trigger execution of a [[runnable entity]] by the [[RTE]]. Thus they can address timing, data sending and receivi..." wikitext text/x-wiki An RTE [[Event]] encompasses all possible situations that can trigger execution of a [[runnable entity]] by the [[RTE]]. Thus they can address timing, data sending and receiving, invoking [[operation]]s, call [[server]] returning, [[mode switch]]ing, or external [[event]]s. RTE Events can either activate a runnable entity or wakeup a runnable entity at its [[wait point]]s. 9bf3ae426ba77b0d8eb0725d68356c833f2c194c 352 351 2013-12-22T22:28:56Z Oliver 1 wikitext text/x-wiki An RTE [[Event]] encompasses all possible situations that can trigger execution of a [[runnable entity]] by the [[RTE]]. Thus they can address timing, data sending and receiving, invoking [[operation]]s, call [[server]] returning, [[mode switch]]ing, or external [[event]]s. RTE Events can either activate a runnable entity or wakeup a runnable entity at its [[wait point]]s. Note ‘event’ in this context is not necessarily synonymous with ‘RTEEvent’ as defined in the [[VFB]] specification. In particular, RTE Events that result from communication are handled by communication-triggered runnable entities. 868f41c47deed440a2d2b1cd3e76cda79a41ddb3 0 313 367 2013-12-22T22:29:27Z Oliver 1 Created page with "A sender-receiver interface is a special kind of [[port-interface]] used for the case of [[sender-receiver communication]]. The sender-receiver interface defines the [[data-el..." wikitext text/x-wiki A sender-receiver interface is a special kind of [[port-interface]] used for the case of [[sender-receiver communication]]. The sender-receiver interface defines the [[data-element]]s which are sent by a sending [[component]] (which has a [[p-port]] providing the sender-receiver interface) or received by a receiving component (which has an [[r-port]] requiring the sender-receiver interface). 2f0127f2871cab4e055ae9012134d24eba1a82a3 0 314 368 2013-12-22T22:30:13Z Oliver 1 Created page with "[[SW-Component]] dedicated to the control of a [[sensor]] or [[actuator]]. There will be several Sensor/ Actuator SW-Cs in each [[ECU]]. In general there will be one Sensor/Ac..." wikitext text/x-wiki [[SW-Component]] dedicated to the control of a [[sensor]] or [[actuator]]. There will be several Sensor/ Actuator SW-Cs in each [[ECU]]. In general there will be one Sensor/Actuator SW-C for each sensor and one for each actuator (=> number of Sensor/Actuator SW-C = number of sensors + number of actuators). ce57fc18fe9d935bffd787e70e11e695c7dfe18f 0 315 369 2013-12-22T22:31:11Z Oliver 1 Created page with "Software entity which provides [[service]]s for [[clients]]. The server and the clients using its service might be located on one [[ECU]] or distributed on different calculati..." wikitext text/x-wiki Software entity which provides [[service]]s for [[clients]]. The server and the clients using its service might be located on one [[ECU]] or distributed on different calculation units (e.g. ECU). 99bee53f3f90b837b49187ffdc197ffa386feef5 0 316 370 2013-12-22T22:31:53Z Oliver 1 Created page with "A service is a type of [[operation]] that has a published specification of interface and behavior, involving a contract between the [[server]] of the capability and the potent..." wikitext text/x-wiki A service is a type of [[operation]] that has a published specification of interface and behavior, involving a contract between the [[server]] of the capability and the potential [[client]]s. dfc1620cfe994964d521152b205843f94c91b88c 0 304 355 2013-12-22T22:32:15Z Oliver 1 Created page with "SAE J1939 is a vehicle [[bus]] standard created by the SAE (Society of Automotive Engineers, a USA standards body) for car and heavy duty truck industries. The J1939 standard ..." wikitext text/x-wiki SAE J1939 is a vehicle [[bus]] standard created by the SAE (Society of Automotive Engineers, a USA standards body) for car and heavy duty truck industries. The J1939 standard encompasses the following areas: - bus physics (J1939/11, J1939/15) - [[CAN]] [[message layout]] (J1939/21) - request/response and multi packet transport protocols (J1939/21) - [[network management]] used to assign a unique address to each node (J1939/81) - diagnostics layer comparable to [[UDS]] in complexity (J1939/73) - standardized application signals and messages (J1939/71) 832f4c68af9259d6346dd95615aed01d4bf78b64 0 84 356 87 2013-12-22T22:32:38Z Oliver 1 wikitext text/x-wiki [[Safety]] Integrity Level da06479165bb9468b359c718079abd955945ad7b 0 317 371 2013-12-22T22:33:11Z Oliver 1 Created page with "A Service Port is a [[Port]] of an [[SW-C]], [[Complex Driver]] and/or [[ECU Abstraction]] connected to an AUTOSAR [[Service]]. The [[interface]] of a Service Port has to be a..." wikitext text/x-wiki A Service Port is a [[Port]] of an [[SW-C]], [[Complex Driver]] and/or [[ECU Abstraction]] connected to an AUTOSAR [[Service]]. The [[interface]] of a Service Port has to be a Standardized [[AUTOSAR Interface]]. A Service Port does not need to be connected to another Port in the [[VFB]] View. 13d65ae70eea77f68941f0bedb6392ca0e14f200 0 24 357 117 2013-12-22T22:33:13Z Oliver 1 wikitext text/x-wiki Automotive [[Safety]] Integrity Levels (ASIL) are used within [[ISO 26262]] to express the level of risk reduction required to prevent a specific hazard, with ASIL D representing the highest and ASIL A the lowest. The ASIL is assigned to the according safety goal and inherited to the safety requirements derived from it. a2b3a32d1ad1eb9d8897e331339914fda1a91349 0 305 358 2013-12-22T22:33:23Z Oliver 1 Created page with "Absence of unreasonable [[risk]]." wikitext text/x-wiki Absence of unreasonable [[risk]]. 05724ddc1de35f0e92a07334d1e4ffc266228fa6 0 306 359 2013-12-22T22:33:40Z Oliver 1 Created page with "A communication protocol defining the necessary mechanisms to ensure the integrity of transmitted data and to detect any communication related error." wikitext text/x-wiki A communication protocol defining the necessary mechanisms to ensure the integrity of transmitted data and to detect any communication related error. e5249af0bfcc3a68c99e785256b41b821db85741 0 318 372 2013-12-22T22:34:49Z Oliver 1 Created page with "The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered..." wikitext text/x-wiki The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Hardware Abstraction Layer]], the Services Layer offers Operating system services Vehicle network communication and management services Memory services (NVRAM management) Diagnosis Services (including KWP2000 interface and error memory) [[ECU]] state management Task: Provide basic services for application and [[basic software module]]s The Services Layer consists of the following parts: Communication Services Memory Services System Services c7d9a68f48c8408faef646a1c8022d00e74de69e 0 319 373 2013-12-22T22:35:25Z Oliver 1 Created page with "Component shipment refers to the action of a supplier releasing a software [[component]] (also a [[composition]]) to the [[system integrator]]. The integrator will gather all ..." wikitext text/x-wiki Component shipment refers to the action of a supplier releasing a software [[component]] (also a [[composition]]) to the [[system integrator]]. The integrator will gather all shipments of the components that make up the whole [[system]] and then map them to [[ECU]]s. 39fc2029acb22ff6d7f17bc5933285c55c8bc3de 0 320 374 2013-12-22T22:36:33Z Oliver 1 Created page with "Software-Components are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Function Bus]] to fulfill archi..." wikitext text/x-wiki Software-Components are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Function Bus]] to fulfill architectural responsibilities. A Software Component has a formal description defined by the [[software component template]]. Software Components can be abbreviated as SW-Cs. 8208315ecaa4aca07fc923bc1779c7c027588e98 0 321 375 2013-12-22T22:37:02Z Oliver 1 Redirected page to [[Software Component Interface]] wikitext text/x-wiki #REDIRECT [[Software Component Interface]] 823a54ef267e35face2d75e27784c777e9f2793e 0 322 376 2013-12-22T22:38:42Z Oliver 1 Created page with "A SoftWare-Component Interface is the sum of all interfaces offered by the [[Basic Software]], towards the [[SW-C]]s. A SW-CI denotes the interface between an SW-C and the und..." wikitext text/x-wiki A SoftWare-Component Interface is the sum of all interfaces offered by the [[Basic Software]], towards the [[SW-C]]s. A SW-CI denotes the interface between an SW-C and the underlying [[Basic Software cluster]] including the [[RTE]]. The SW-CI therefore comprises all [[API]], [[function]]s and [[Callback]]s that the SW-C requires from and provides to the Basic Software (generally by means of RTE mechanisms). It includes also the mechanisms allowing SW-Cs sharing the SW-CI to communicate with one another. For the purposes of this definition, the Basic Software clustered on an [[ECU]] can be designed according to [[ICC1]], [[ICC2]] and [[ICC3]]. 4668bc5138f5de23ea38a3ee984a78b9361d7631 0 323 377 2013-12-22T22:39:52Z Oliver 1 Created page with "The arrangement of [[software element]]s in a SW [[system]]. A software element is a clearly definable software part. A software configuration is a selection version of [[soft..." wikitext text/x-wiki The arrangement of [[software element]]s in a SW [[system]]. A software element is a clearly definable software part. A software configuration is a selection version of [[software module]]s, [[software component]]s, [[parameter]]s and generator configurations. [[Calibration]] and [[Variant Coding]] can be regarded as subset of Software Configuration. 2521f02d76e0e25898b16c77050abfca930e989e 0 324 378 2013-12-22T22:40:42Z Oliver 1 Created page with "[[Interrupt]] triggered by SW [[event]]. SW events are for example calling an [[operating system service]], starting a process with higher priority." wikitext text/x-wiki [[Interrupt]] triggered by SW [[event]]. SW events are for example calling an [[operating system service]], starting a process with higher priority. f2bff2e6b0a3614baf420d64b83930246a8a2c25 0 325 379 2013-12-22T22:41:39Z Oliver 1 Created page with "A collection of software files (code and description) that define a certain software functionality present on an [[ECU]]. A software module may be an Atomic [[SW-C]], or a [[B..." wikitext text/x-wiki A collection of software files (code and description) that define a certain software functionality present on an [[ECU]]. A software module may be an Atomic [[SW-C]], or a [[Basic Software module]], or the [[RTE]] (RunTimeEnvironment). 222947fe52ec36aae546cbbc45002136955f014c 0 326 380 2013-12-22T22:42:16Z Oliver 1 Created page with "A Software Signal is an asynchronous [[event]] transmitted between one [[process]] and another. A SW Signal is the software implementation of an (control-) information. Additi..." wikitext text/x-wiki A Software Signal is an asynchronous [[event]] transmitted between one [[process]] and another. A SW Signal is the software implementation of an (control-) information. Additionally it may have attributes (e.g. freshness, data type, …). It is exchanged between [[SW-Components]]. e6ebefb6ddf0cf34b32cd9876e2e8ef73162fdba 0 327 381 2013-12-22T22:42:43Z Oliver 1 Created page with "Special functions to standard peripheral devices or special peripherals. Is only used when, because of technical issues, no standard periphery access can be used." wikitext text/x-wiki Special functions to standard peripheral devices or special peripherals. Is only used when, because of technical issues, no standard periphery access can be used. e7b2cd193f2925c09befc127e9c75c4ad7ef7379 382 381 2013-12-22T22:43:07Z Oliver 1 wikitext text/x-wiki Special functions to standard peripheral devices or special peripherals. Is only used when, because of technical issues, no [[standard periphery access]] can be used. 290f4f675d506fd560867c3802351f36a0166752 0 328 383 2013-12-22T22:43:20Z Oliver 1 Created page with "Standard functions to typical standard peripheral devices that is available on an [[ECU]] (most microcontroller integrated) used in automotive embedded applications." wikitext text/x-wiki Standard functions to typical standard peripheral devices that is available on an [[ECU]] (most microcontroller integrated) used in automotive embedded applications. 1c010c1482bfdfde456bbd5f369055ad141c50f1 0 329 384 2013-12-22T22:43:53Z Oliver 1 Created page with "This is an AUTOSAR Interface which is standardized within the AUTOSAR project. AUTOSAR Services interact with other [[component]]s through a Standardized AUTOSAR Interface." wikitext text/x-wiki This is an AUTOSAR Interface which is standardized within the AUTOSAR project. AUTOSAR Services interact with other [[component]]s through a Standardized AUTOSAR Interface. 31c5a7e168755f0004d191fe7270a82add7818e3 0 330 385 2013-12-22T22:44:20Z Oliver 1 Created page with "A software interface is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[Basic Software]] interact which each other through Standardiz..." wikitext text/x-wiki A software interface is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[Basic Software]] interact which each other through Standardized Interfaces. 2545c017f5e8e542fe41be36ba134c427c7657d7 0 331 386 2013-12-22T22:45:01Z Oliver 1 Created page with "Standard Software is software which provides schematic independent infrastructural functionalities on an [[ECU]]. It contains only [[Standardized Interfaces]], [[Standardized ..." wikitext text/x-wiki Standard Software is software which provides schematic independent infrastructural functionalities on an [[ECU]]. It contains only [[Standardized Interfaces]], [[Standardized AUTOSAR Interfaces]] and/or [[Private Interfaces]]. 71518518966049dc166a04143353e85cacf7a515 0 332 387 2013-12-22T22:45:53Z Oliver 1 Created page with "A setup where the [[routing]] configuration cannot be changed during normal operation of the [[gateway]]. Static configuration doesn't allow reconfiguration of the routing dur..." wikitext text/x-wiki A setup where the [[routing]] configuration cannot be changed during normal operation of the [[gateway]]. Static configuration doesn't allow reconfiguration of the routing during normal operation e.g. during driving. Static configuration does not restrict the update of the configuration in specific maintenance operation modes (e.g. [[programming mode]]). a8fc2cebb695ef7266d6978602140b03343384ec 0 333 388 2013-12-22T22:46:38Z Oliver 1 Created page with "Systematic iteration of a reduced [[full-set assessment]] as a basis for maintaining the validity of the full-set assessment. Within AUTOSAR context, reduced set surveillances..." wikitext text/x-wiki Systematic iteration of a reduced [[full-set assessment]] as a basis for maintaining the validity of the full-set assessment. Within AUTOSAR context, reduced set surveillances of the accredited party are scheduled yearly between the full-set assessments. 06dd7693cbacd56929695c9e0b2f18bfd898fcbe 0 334 389 2013-12-22T22:46:56Z Oliver 1 Created page with "To make two or more events or operations to occur at the same predefined moment in time." wikitext text/x-wiki To make two or more events or operations to occur at the same predefined moment in time. 6a49534011ef8775b06ba93bd399ffef3d298207 390 389 2013-12-22T22:47:07Z Oliver 1 wikitext text/x-wiki To make two or more [[event]]s or operations to occur at the same predefined moment in time. e638806e81afc027e4a02cc3e0433d44e8a519a3 0 335 391 2013-12-22T22:47:52Z Oliver 1 Created page with "A communication is synchronous when the calling software [[entity]] is blocked until the called operation is evaluated. The calling software entity continues its operation by ..." wikitext text/x-wiki A communication is synchronous when the calling software [[entity]] is blocked until the called operation is evaluated. The calling software entity continues its operation by getting the result. Synchronous communication between [[distributed functional unit]]s has to be implemented as [[remote procedure call]]. 1d0d2b910d434b41f1ef40c2b4edbf57f1884861 0 336 392 2013-12-22T22:48:23Z Oliver 1 Created page with "An integrated composite that consists of one or more of the [[process]]es, hardware, software, facilities and people, that provides a capability to satisfy a stated need or ob..." wikitext text/x-wiki An integrated composite that consists of one or more of the [[process]]es, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. 7a51d67c2fe13c1aeba8449f7294ff376e563111 0 337 393 2013-12-22T22:49:13Z Oliver 1 Created page with "Boundary conditions that restrict the Design-Freedom of the (cars E/E-) [[System]]. The design of [[ECU Network]]s and the distribution of functionalities to [[ECU]]s are limi..." wikitext text/x-wiki Boundary conditions that restrict the Design-Freedom of the (cars E/E-) [[System]]. The design of [[ECU Network]]s and the distribution of functionalities to [[ECU]]s are limited by several constrains. These constraints result mostly by the [[communication matrix]] and safety requirements. 2fe400df0c4866763da963c7390602089332f55d 0 338 394 2013-12-22T22:51:55Z Oliver 1 Created page with "The system [[signal]] represents the communication system's view of data exchanged between [[SW component]]s which reside on different [[ECU]]s. The [[system]] signals allow t..." wikitext text/x-wiki The system [[signal]] represents the communication system's view of data exchanged between [[SW component]]s which reside on different [[ECU]]s. The [[system]] signals allow to represent this communication in a flattened structure, with (at least) one system signal defined for each data element sent or received by a SW component instance. If data has to be sent over gateways, there is still only one system signal representing this data. The representation of the data on the individual communication systems is done by the cluster signals. d0978936c17f61885112758d8ad9a32724347053 0 339 395 2013-12-22T22:52:39Z Oliver 1 Created page with "A Task is the smallest schedulable unit managed by the [[OS]]. The OS decides when which task can run on the [[CPU]] of the [[ECU]]. A [[runnable entity]] of a [[software comp..." wikitext text/x-wiki A Task is the smallest schedulable unit managed by the [[OS]]. The OS decides when which task can run on the [[CPU]] of the [[ECU]]. A [[runnable entity]] of a [[software component]] runs in the context of a task. Also the [[Basic Software Module]]s runs in the context of a task. cde8a95b7bdb61e76bf7c9c523491860a35c372f 0 340 396 2013-12-22T22:53:14Z Oliver 1 Created page with "The technical signal is the physical value of an external [[event]] coupled to an AUTOSAR system. Technical signals are represented in SI units (e.g. pressure in PA). The term..." wikitext text/x-wiki The technical signal is the physical value of an external [[event]] coupled to an AUTOSAR system. Technical signals are represented in SI units (e.g. pressure in PA). The term Technical Signal is used when we are referring to the "real world" signal that is under consideration. So typical Technical Signals are temperature, velocity, torque, force, electrical current and voltage, etc. 5ff20636722034cc4b95490ddb71374ce69e7f16 0 341 397 2013-12-22T22:54:25Z Oliver 1 Created page with "A template is a structured collection of attributes that are required to formally describe AUTOSAR [[artifact]]s like e.g. [[software component]]s or [[configuration]]s of [[E..." wikitext text/x-wiki A template is a structured collection of attributes that are required to formally describe AUTOSAR [[artifact]]s like e.g. [[software component]]s or [[configuration]]s of [[ECU]]s. The term "Template" stresses the fact that the collected attributes still need to have actual values assigned in order to describe a particular artifact. Those values are collected in a [[Description]]. Templates are independent of the technology used for serialization of their respective descriptions. Possible serializations include [[XML]], databases tables and so on. c940729be666d8ee6112873c30e5ddbd60ec0f15 0 342 398 2013-12-22T22:55:15Z Oliver 1 Created page with "An organization that is independent of the organization that provides automotive products, which are subject to [[AUTOSAR conformance testing]]. Criteria for the independence ..." wikitext text/x-wiki An organization that is independent of the organization that provides automotive products, which are subject to [[AUTOSAR conformance testing]]. Criteria for the independence of [[conformity assessment]] bodies and [[accreditation]] bodies are provided in the International Standard and Guides applicable to their activities. 1c3ca4f4eead4481e19d52fcc0d2dacdc9ef8cd3 0 343 399 2013-12-22T22:55:38Z Oliver 1 Created page with "Notification with respect to deadline violation of an [[event]] or [[task]] (e.g. while working on/with information: receiving, sending, processing,...)." wikitext text/x-wiki Notification with respect to deadline violation of an [[event]] or [[task]] (e.g. while working on/with information: receiving, sending, processing,...). 3ad7a983d873ed0fa7a3d051c95f37fc049bc0a1 0 122 400 133 2013-12-22T23:05:59Z Oliver 1 wikitext text/x-wiki “Bulk Data” is a set of data such big in size, that standard mechanisms used to handle smaller data sets become inconvenient. This implies that bulk data in a software system are modeled, stored, accessed and transported by different mechanisms than smaller data sets. Bulk data are typically handled by adding a level of abstraction (e.g. files) which separates the containment of the data from the internal structure. The critical size, above which data must be regarded as bulk data depends on the technical infrastructure (e.g. bus system) and the considered [[use case]] (transport, storage etc.). 489d03acf36b5e5f1e181d54961592064b49baca 0 180 401 208 2013-12-22T23:06:20Z Oliver 1 wikitext text/x-wiki The term feature is commonly used in the [[software tool]] community to describe characteristics (functionality) of the software. In AUTOSAR a feature is represented by one or many meta classes and their attributes in the AUTOSAR [[meta-model]]. Features are used to implement [[use case]]s such that a single use case requires one or more features for implementation. 7c766c33bd1642453c4d3daf95c2888599235f66 0 344 402 2013-12-22T23:06:43Z Oliver 1 Created page with "A [[model]] of the usage by the user of a [[system]] in order to realize a certain functional feature of the system." wikitext text/x-wiki A [[model]] of the usage by the user of a [[system]] in order to realize a certain functional feature of the system. 7dd3d6aaeaedf8e1e69eb5757b1f0a403a613262 0 345 403 2013-12-22T23:08:40Z Oliver 1 Created page with "Confirmation by examination and provisions of objective evidence that the particular requirements for a specific intended use are fulfilled. In design and development, validat..." wikitext text/x-wiki Confirmation by examination and provisions of objective evidence that the particular requirements for a specific intended use are fulfilled. In design and development, validation concerns the process of examining a product to determine [[conformity]] with user needs. Validation is normally performed on the final product under defined operating conditions. It may be necessary in earlier stages. “Validated” is used to designate the corresponding status. Multiple validations may be carried out if there are different intended uses. [ISO 8402: 1994] 059157a7b410f5adc215f540b868faa57ba804f7 0 346 404 2013-12-22T23:09:07Z Oliver 1 Created page with "Variability of a [[system]] is its quality to describe a set of [[variant]]s. These variants are characterized by variant specific property settings and / or selections." wikitext text/x-wiki Variability of a [[system]] is its quality to describe a set of [[variant]]s. These variants are characterized by variant specific property settings and / or selections. 6d86b1b1fa197d211131eec5a5af4e992e4a9e31 0 347 405 2013-12-22T23:09:44Z Oliver 1 Created page with "A system variant is a concrete realization of a [[system]], so that all its properties have been set respectively selected. The [[software system]] has no variability anymore ..." wikitext text/x-wiki A system variant is a concrete realization of a [[system]], so that all its properties have been set respectively selected. The [[software system]] has no variability anymore with respect to the binding time. 7c0863161eee30b43b9094b510dfe42618d93ecc 0 348 406 2013-12-22T23:10:52Z Oliver 1 Created page with "Adaptation of [[SW]] by selection of functional alternatives according to external requirements (e.g. country-dependent or legal restrictions). The major difference with [[cal..." wikitext text/x-wiki Adaptation of [[SW]] by selection of functional alternatives according to external requirements (e.g. country-dependent or legal restrictions). The major difference with [[calibration]] is that this later doesn’t aim to adapt the SW functionality itself but only aims to adjust the SW to the HW/SW environment, e.g. the calibration of engine control SW that is adjusted to the physical parameters of every engine. Variant Coding also includes [[vehicle-specific]] (not [[user-specific]]) SW adaptation due to end-customer wishes (e.g. deactivation of speed-dependent automatic locking). Variant Coding is always done after compile time. Used techniques to select variants include end-of-line programming and garage programming. 983ee6378a488a7ce4891ee97c273d08470eba80 0 349 407 2013-12-22T23:11:21Z Oliver 1 Created page with "A [[variant]] is the result of a variation binding process that resolves the variability of the [[system]] by assigning particular values/selections to all the system’s prop..." wikitext text/x-wiki A [[variant]] is the result of a variation binding process that resolves the variability of the [[system]] by assigning particular values/selections to all the system’s properties. 1e4604803c8b903e443728238ce44700356ddad9 0 350 408 2013-12-22T23:11:43Z Oliver 1 Created page with "The variation binding time determines the step in the [[methodology]] at which the variability given by a set of variable properties is resolved." wikitext text/x-wiki The variation binding time determines the step in the [[methodology]] at which the variability given by a set of variable properties is resolved. 55cdaa17406f7d9eec37c54cc5ebe3f4e4be6e22 0 351 409 2013-12-22T23:12:04Z Oliver 1 Created page with "The variation definition time determines the step in the [[methodology]] at which the variation points are defined." wikitext text/x-wiki The variation definition time determines the step in the [[methodology]] at which the variation points are defined. b31bee39cca3f3285da3acfbe75373ccb1f2b39f 0 352 410 2013-12-22T23:12:37Z Oliver 1 Created page with "A [[variation]] point indicates that a [[property]] is subject to variation. Furthermore, it is associated with a condition and a binding time which define the [[system]] cont..." wikitext text/x-wiki A [[variation]] point indicates that a [[property]] is subject to variation. Furthermore, it is associated with a condition and a binding time which define the [[system]] context for the selection / setting of a concrete [[variant]]. 1f4ac7b1128246a8db9cbf5932ad13852c13f057 0 353 411 2013-12-22T23:13:41Z Oliver 1 Created page with "A vendor ID is a unique identification of the [[vendor]] of a [[software component]]. All [[basic software module]]s conformant to the AUTOSAR standard shall provide a readabl..." wikitext text/x-wiki A vendor ID is a unique identification of the [[vendor]] of a [[software component]]. All [[basic software module]]s conformant to the AUTOSAR standard shall provide a readable vendor ID. AUTOSAR Vendor IDs are used to determine vendors of basic software modules before and during runtime. The mechanism is used to improve [[bug]] handling. AUTOSAR currently only provides Vendor IDs to members of the AUTOSAR partnership. 9e52aea35d53f6420057ea725320c0dd07eabce0 0 354 412 2013-12-22T23:14:21Z Oliver 1 Created page with "Confirmation by examination and provisions of objective evidence that specified requirements have been fulfilled. In design and development, verification concerns the process ..." wikitext text/x-wiki Confirmation by examination and provisions of objective evidence that specified requirements have been fulfilled. In design and development, verification concerns the process of examining the result of a given activity to determine conformity with the stated requirement for that activity. “Verified” is used to designate the corresponding status. [ISO 8402: 1994] 449ae3863807724739cd84b820bf9af04c4ffcae 0 317 413 371 2013-12-22T23:14:45Z Oliver 1 wikitext text/x-wiki A Service Port is a [[Port]] of an [[SW-C]], [[Complex Driver]] and/or [[ECU Abstraction]] connected to an AUTOSAR [[Service]]. The [[interface]] of a Service Port has to be a Standardized [[AUTOSAR Interface]]. A Service Port does not need to be connected to another Port in the [[VFB View]]. 500cb4b9045580e5c7e675362d29f19c007b42ac 0 355 414 2013-12-22T23:16:13Z Oliver 1 Created page with "The [[VFB]] View describes [[system]]s or subsystems in the car independently of these resources; in other words, independently of: -what kind of and how many [[ECU]]s are pre..." wikitext text/x-wiki The [[VFB]] View describes [[system]]s or subsystems in the car independently of these resources; in other words, independently of: -what kind of and how many [[ECU]]s are present in the car -on what ECUs the entities in the VFB-View run -how the ECUs are interconnected: what kind of network technology ([[CAN]], [[LIN]],…) and what kind of [[topology]] (presence of [[gateway]]s) is used. In the VFB-View, the system or [[subsystem]] under consideration is a [[Composition]] which consists out of [[Connector]]s and [[Component]]s. 6a53c970ac94b78ba21bb23169010f9a9960c974 0 94 415 97 2013-12-22T23:16:39Z Oliver 1 Redirected page to [[Virtual Functional Bus]] wikitext text/x-wiki #REDIRECT [[Virtual Functional Bus]] f49760b1c3a9863ae2b207ec70de557ebe6c8090 0 356 416 2013-12-22T23:17:28Z Oliver 1 Created page with "The Virtual Functional Bus is an abstraction of the communication between [[Atomic Software Component]]s and [[AUTOSAR Services]]. This abstraction is such that specification ..." wikitext text/x-wiki The Virtual Functional Bus is an abstraction of the communication between [[Atomic Software Component]]s and [[AUTOSAR Services]]. This abstraction is such that specification of the communication mechanisms is independent from the concrete technology chosen to realize the communication. After compilation and linking of software for a dedicated [[ECU]] the Virtual Functional Bus interfaces are realized by the AUTOSAR [[Runtime Environment]]. 737d24b783722d1c35d2b99d8f10fc346df8e8af 0 82 417 85 2013-12-22T23:17:50Z Oliver 1 Redirected page to [[Runtime Environment]] wikitext text/x-wiki #REDIRECT [[Runtime Environment]] cb243d280c9afd8f5b2aba6359d10094474e9861 0 357 418 2013-12-22T23:18:35Z Oliver 1 Created page with "The simulated, modeled and/or calculated (not real) combination of software entities forming a [[system]]. By virtual integration several constraints and/or requirements are c..." wikitext text/x-wiki The simulated, modeled and/or calculated (not real) combination of software entities forming a [[system]]. By virtual integration several constraints and/or requirements are checked without the need of real hardware units, like needed CPU load, needed memory, completeness of interfaces, fulfillment of timing requirements etc.). 10414cefb4f9152ee8a432648a9f01f7ccbea3bc 0 96 419 189 2013-12-22T23:19:18Z Oliver 1 Redirected page to [[Worst Case Execution Time]] wikitext text/x-wiki #REDIRECT [[Worst Case Execution Time]]. 9f067519d9ed5ed07885b73d2d383a879d2b4259 0 358 420 2013-12-22T23:20:10Z Oliver 1 Created page with "Maximum possible time during which a program is actually executing. The worst case [[execution time]] of a piece of software is the maximum possible time during which the CPU ..." wikitext text/x-wiki Maximum possible time during which a program is actually executing. The worst case [[execution time]] of a piece of software is the maximum possible time during which the CPU is executing instructions which belong to this piece. The worst case execution time is often identified by analytical methods. It is required to determine if a schedule meets the overall timing requirements. Abbreviation: WCET See also: [[response time]], [[execution time]], [[worst case response time]] ebfe0605e49d61f679d5aec3629a40e5cceee28a 0 97 421 346 2013-12-22T23:20:45Z Oliver 1 Redirected page to [[Worst Case Response time]] wikitext text/x-wiki #REDIRECT [[Worst Case Response time]] dc936b5069271e612d9db7f5d4b722d8cc5bb762 0 359 422 2013-12-22T23:21:39Z Oliver 1 Redirected page to [[Worst Case Response Time]] wikitext text/x-wiki #REDIRECT [[Worst Case Response Time]] 4a9dc123c38803c04da5a751f58fa5aa81b5ba32 0 360 423 2013-12-22T23:21:58Z Oliver 1 Created page with "Maximum possible time between receiving a stimulus and delivering an appropriate response or reaction. The worst case [[response time]] describes the maximum possible time bet..." wikitext text/x-wiki Maximum possible time between receiving a stimulus and delivering an appropriate response or reaction. The worst case [[response time]] describes the maximum possible time between a stimulus like e.g. the state change of hardware or software entity and the expected reaction of the [[system]] (e.g. response, [[actuator]] activation). Typically: worst-case execution-time + infrastructure-overhead + scheduling-policy = worst-case reaction time Further Explanations Synonym: worst case reaction time See also: [[response time]], [[execution time]], [[worst case execution time]] 79124ddde6f90a9b3016dd01834f806ac65d3c80 424 423 2013-12-22T23:22:09Z Oliver 1 wikitext text/x-wiki Maximum possible time between receiving a stimulus and delivering an appropriate response or reaction. The worst case [[response time]] describes the maximum possible time between a stimulus like e.g. the state change of hardware or software entity and the expected reaction of the [[system]] (e.g. response, [[actuator]] activation). Typically: worst-case execution-time + infrastructure-overhead + scheduling-policy = worst-case reaction time Synonym: worst case reaction time See also: [[response time]], [[execution time]], [[worst case execution time]] 163f5c9864dc8a6f6b62711c4e5961d6e2faf532 0 361 425 2013-12-22T23:37:26Z Oliver 1 Created page with "Bitfield functions for fixed point." wikitext text/x-wiki Bitfield functions for fixed point. 99530dc7d2717ae67c4e63baff5d767cb93fbfc3 0 362 426 2013-12-22T23:37:49Z Oliver 1 Redirected page to [[Cyclic Redundancy Check]] wikitext text/x-wiki #REDIRECT [[Cyclic Redundancy Check]] 1a4c66b7283a46bb9d85a98f49a66fcf84ffe53e 0 363 427 2013-12-22T23:38:30Z Oliver 1 Redirected page to [[End to End]] wikitext text/x-wiki #REDIRECT [[End to End]] 42da14e606e1962fef6c814ba770beb168789db0 0 364 428 2013-12-22T23:38:46Z Oliver 1 Created page with "Electrically Erasable Programmable Read-Only Memory" wikitext text/x-wiki Electrically Erasable Programmable Read-Only Memory 7502558e08da60094b90e55fe6c5b75e6a89bbe1 0 365 429 2013-12-22T23:38:59Z Oliver 1 Created page with "Extended Mathematical library – Fixed point" wikitext text/x-wiki Extended Mathematical library – Fixed point 58f95bd5b1f9c7a346128b4fd5a4b55883fe7241 0 366 430 2013-12-22T23:39:16Z Oliver 1 Redirected page to [[General Purpose Timer]] wikitext text/x-wiki #REDIRECT [[General Purpose Timer]] 95c8b48afbb2dc5cf8ac7072a8bc691b4875643e 0 367 431 2013-12-22T23:39:33Z Oliver 1 Redirected page to [[Input Capture Unit]] wikitext text/x-wiki #REDIRECT [[Input Capture Unit]] 368464b0f08798d535eef7d8058b162a70114cb2 0 368 432 2013-12-22T23:39:50Z Oliver 1 Redirected page to [[Interpolation Floating point]] wikitext text/x-wiki #REDIRECT [[Interpolation Floating point]] 038d98a970f27c913ee20219dee48bdfb5912512 0 369 433 2013-12-22T23:40:10Z Oliver 1 Redirected page to [[Interpolation Fixed point]] wikitext text/x-wiki #REDIRECT [[Interpolation Fixed point]] 5909889d621a914e0119e64a2d1d56c836a1d5fb 0 370 434 2013-12-22T23:40:25Z Oliver 1 Created page with "Input/Output" wikitext text/x-wiki Input/Output c05e081250483115acb3291c729e966cb6237c5d 0 371 435 2013-12-22T23:40:47Z Oliver 1 Redirected page to [[Micro Controller Unit]] wikitext text/x-wiki #REDIRECT [[Micro Controller Unit]] 72437698631e6ae2f0f2947faf84f588e00e9f4f 0 372 436 2013-12-22T23:41:02Z Oliver 1 Redirected page to [[Mathematical Floating point]] wikitext text/x-wiki #REDIRECT [[Mathematical Floating point]] bb25a13c4d18caa9bd775d84156e4c4942a24d73 0 373 437 2013-12-22T23:41:12Z Oliver 1 Created page with "Math – Fixed Point" wikitext text/x-wiki Math – Fixed Point f9d0e96eb211dfd5cf8adccee890a5047abb9ed4 0 374 438 2013-12-22T23:41:33Z Oliver 1 Created page with "Serial Peripheral Interface" wikitext text/x-wiki Serial Peripheral Interface cff5620a3150f403cc83b5b809f29e822cf431e8 0 375 439 2013-12-22T23:42:07Z Oliver 1 Redirected page to [[Software Specification]] wikitext text/x-wiki #REDIRECT [[Software Specification]] b50ca8ec015970aeffdfafbad3937b26d4986628 0 376 440 2013-12-22T23:42:20Z Oliver 1 Created page with "Time Triggered [[CAN]]" wikitext text/x-wiki Time Triggered [[CAN]] 9f79ea5dc4b9a251562a0277bb037b7a89b0be51 0 377 441 2013-12-23T00:29:28Z Oliver 1 Created page with "Debug With Arbitrary Record Format" wikitext text/x-wiki Debug With Arbitrary Record Format 110a8a3ad8c517067801467627166e3e2db0679e 0 87 442 90 2013-12-23T00:30:31Z Oliver 1 Redirected page to [[Software Component]] wikitext text/x-wiki #REDIRECT [[Software Component]] 1b400e021eae68abe0c8a724614f9c7de4209b9a 0 4 443 6 2013-12-26T22:47:15Z Oliver 1 wikitext text/x-wiki A “Basic Storage Object” is the smallest entity of a “[[NVRAM Block]]”. Several “Basic Storage Objects” can be used to build a [[NVRAM Block]]. A “Basic Storage Object“ can reside in different memory locations ([[RAM]]/[[ROM]]/[[NVRAM]]). 47d6e14bfec9165e911ece9b6ae735d2daf6d897 0 320 444 374 2013-12-26T23:12:15Z Oliver 1 wikitext text/x-wiki Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Function Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the [[software component template]]. Software Components can be abbreviated as SW-Cs. 1d2c967f3066d76501a40eda52c8781247b467b2 0 275 445 323 2013-12-26T23:13:44Z Oliver 1 wikitext text/x-wiki A port belongs to exactly one [[software component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[p-port]] or an [[r-port]]. 44b82e637c3aabab21945427b67a8aac2451d3c6 451 445 2013-12-26T23:29:19Z Oliver 1 wikitext text/x-wiki A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[p-port]] or an [[r-port]]. A port of a SW-C is associated with a port-interface. da5d99ccbc1346c3a29c431cc73a678e5d72d725 452 451 2013-12-26T23:29:30Z Oliver 1 wikitext text/x-wiki A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[p-port]] or an [[r-port]]. A port of a SW-C is associated with a [[port-interface]]. c7c480a19780b8a87951dc45567981ce604e85db 0 378 446 2013-12-26T23:16:34Z Oliver 1 Redirected page to [[Sensor/Actuator SW-Component]] wikitext text/x-wiki #REDIRECT [[Sensor/Actuator SW-Component]] 69caa31247b3552e62849acbec6b6bca90ff390b 0 314 447 368 2013-12-26T23:17:14Z Oliver 1 wikitext text/x-wiki [[Software Component]] dedicated to the control of a [[sensor]] or [[actuator]]. There will be several Sensor/ Actuator SW-Cs in each [[ECU]]. In general there will be one Sensor/Actuator SW-C for each sensor and one for each actuator (=> number of Sensor/Actuator SW-C = number of sensors + number of actuators). 221b3c5f1736d515f50731d8d0ee87c72b3a5a24 0 207 448 240 2013-12-26T23:18:07Z Oliver 1 Redirected page to [[FlexRay Slot Number]] wikitext text/x-wiki #REDIRECT [[FlexRay Slot Number]] 18ed1c4de8907019a9709c3447f628a74ae1e8ae 0 18 449 20 2013-12-26T23:19:13Z Oliver 1 Redirected page to [[Non-volatile memory]] wikitext text/x-wiki #REDIRECT [[Non-volatile memory]] 43e1f466eba6ae78dae6ec60cece796912df7059 0 30 450 33 2013-12-26T23:23:56Z Oliver 1 Redirected page to [[Complex Device Driver]] wikitext text/x-wiki #REDIRECT [[Complex Device Driver]] d66deb860d48b172f211a7067c424bc105c6bfae 0 379 453 2013-12-26T23:29:46Z Oliver 1 Redirected page to [[Port Interface]] wikitext text/x-wiki #REDIRECT [[Port Interface]] 10b2f9b998ce3c74cc935c2d254d836c145fbc11 0 276 454 324 2013-12-26T23:30:16Z Oliver 1 wikitext text/x-wiki A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[client-server communication]] is chosen or a [[sender-receiver Interface]] in case [[sender-receiver communication]] is used. e1aae248a8ec915ad5693f0c07f63aaf39cac071 455 454 2013-12-26T23:30:54Z Oliver 1 wikitext text/x-wiki A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[Client-Server communication]] is chosen or a [[Sender-Receiver Interface]] in case [[Sender-Receiver communication]] is used. 795e81e415cc00d698f0ff48d5836d2d4f7a3363 0 276 456 455 2013-12-26T23:31:34Z Oliver 1 wikitext text/x-wiki A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[Client-Server communication]] is chosen or a [[Sender-Receiver Interface]] in case [[Sender-Receiver communication]] is used. It defines the contract that must be fulfilled by the port providing or requiring that interface. b8e40834232eae8d8f8fc801b04eccef29c83b3f 457 456 2013-12-26T23:33:47Z Oliver 1 wikitext text/x-wiki A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[Client-Server communication]] is chosen or a [[Sender-Receiver Interface]] in case [[Sender-Receiver communication]] is used. Further more it can also be a [[Parameter Interface]], [[Non Volatile Data Interface]], [[Trigger Interface]] or [[Mode Switch Interface]]. It defines the contract that must be fulfilled by the port providing or requiring that interface. eff42f9fe6a83bb680e7def19b84043ae37d56b2 0 380 458 2013-12-26T23:34:57Z Oliver 1 Created page with "A parameter [[interface]] allows [[Software Component]]s access to either constant data, fixed data or calibration data. It should be noted that depending on the type of acces..." wikitext text/x-wiki A parameter [[interface]] allows [[Software Component]]s access to either constant data, fixed data or calibration data. It should be noted that depending on the type of access (i.e. fixed, const or standard respectively) that compatibility rules apply. For example a parameter interface which uses a fixed implementation policy will not be allowed to connect to a [[port]] of a Parameter SW Component if the provider uses a variable data implementation (i.e. standard). The reason is plain and simple; The application will use a #define (pre-compile value optimization) and so will not take actual values from the Parameter SW component at runtime. 530c8d783139b082f58f2a8ecff06addcf2644de 477 458 2013-12-27T22:09:52Z Oliver 1 wikitext text/x-wiki A parameter [[interface]] allows [[Software Component]]s access to either constant data, fixed data or calibration data. It should be noted that depending on the type of access (i.e. fixed, const or standard respectively) that compatibility rules apply. For example a parameter interface which uses a fixed implementation policy will not be allowed to connect to a [[port]] of a [[Parameter Software Component]] if the provider uses a variable data implementation (i.e. standard). The reason is plain and simple; The application will use a #define (pre-compile value optimization) and so will not take actual values from the Parameter SW component at runtime. 62a1c690487968e8821e70d74638ac084c272b9b 0 381 459 2013-12-26T23:35:32Z Oliver 1 Created page with "Provide element level access (read only or read/write) to [[Non Volatile Data]] as opposed to [[NV block]] access." wikitext text/x-wiki Provide element level access (read only or read/write) to [[Non Volatile Data]] as opposed to [[NV block]] access. df0043c73861f1132c5a241b785958ceb9650061 0 382 460 2013-12-26T23:36:18Z Oliver 1 Created page with "The trigger [[interface]] allows [[Software Components]] to trigger the execution of other software components. The purpose of the trigger interface is to allow for fast respo..." wikitext text/x-wiki The trigger [[interface]] allows [[Software Components]] to trigger the execution of other software components. The purpose of the trigger interface is to allow for fast response times with regards to the occurrence of a trigger which might occur sporadic or at a variable cycle time. Example: triggering based on the crank shaft and cam shaft position. c8d91f4d91e8e77ce945395371e5d57dc33cfede 0 383 461 2013-12-26T23:37:01Z Oliver 1 Created page with "The mode switch [[interface]] is used to notify a [[Software Component]] of a [[mode]]. The [[Mode Manager]] provides modes that can be used by [[mode user]]s to adjust the be..." wikitext text/x-wiki The mode switch [[interface]] is used to notify a [[Software Component]] of a [[mode]]. The [[Mode Manager]] provides modes that can be used by [[mode user]]s to adjust the behavior according to modes or synchronize activities to mode switches. d1ceeb542fa7e82589c64503b24b0e0c9fddbd6e 0 134 462 145 2013-12-26T23:38:09Z Oliver 1 wikitext text/x-wiki The client-server interface is a special kind of [[port-interface]] used for the case of [[client-server communication]]. The client-server interface defines the operations that are provided (implemented) by the [[server]] and that can be used by the [[client]]. c8e83b9e95db0985a23a2e0f0817445b3e7b4084 0 286 463 334 2013-12-26T23:43:49Z Oliver 1 wikitext text/x-wiki Specific [[Port]] providing [[data]] or providing a [[service]] of a [[server]] as defined in the [[Port Interface]]. The Provide Port is sometimes abbreviated as PPort or P-Port. 7f0378fdaccf27d95222c67bcc82da87bfe52e0f 0 293 464 341 2013-12-26T23:44:13Z Oliver 1 wikitext text/x-wiki Specific [[Port]] requiring [[data]] or requiring a [[service]] of a [[server]] as defined in the [[Port Interface]]. The Require Port is sometimes abbreviated as RPort or R-Port. 488a9f9531c3798adc6c8b4df5d868159b644b4a 0 144 465 158 2013-12-27T00:13:53Z Oliver 1 wikitext text/x-wiki A connector connects [[Port]]s of [[Software Components]] (SW-C) and represents the flow of information between those ports. During the design of an [[AUTOSAR system]], ports between Software Components that need to communicate with each other are hooked up using [[Assembly Connector]]s. Such an Assembly Connector connects one [[RPort]] with one [[PPort]]. 9c63b3f8a37b327cef13511fbd707a54d14a9e90 0 312 466 366 2013-12-27T00:15:23Z Oliver 1 wikitext text/x-wiki A communication pattern which offers asynchronous distribution of information where a [[sender]] communicates information to one or more [[receiver]]s, or a receiver receives information from one or several senders. The process of sending data does not block the sender and the sender usually gets no response from the receivers. Both for Sender-Receiver Communication and for [[Client-Server Communication]], one [[PPort]] can be connected to one or more [[RPorts]] (for multicast sending and multiple [[client]]s connected to a [[server]], respectively). 3a1f338c04acccfc0ae0c2bcb7234161a2847915 0 275 467 452 2013-12-27T00:17:28Z Oliver 1 wikitext text/x-wiki A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[p-port]] or an [[r-port]]. A port of a SW-C is associated with a [[port-interface]]. The occurrence of an unconnected port is not per se a design mistake. It can be valid when an application provider for the [[data element]] is absent and the default init value is good enough to operate with or it could be that an end point was removed from the [[system]] because it is subjected to variability (See [[Variant Handling]]). ef2f5955e5e95e8eaa6c906d7801702f94cd1008 468 467 2013-12-27T00:22:58Z Oliver 1 wikitext text/x-wiki A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[p-port]] or an [[r-port]]. A port of a SW-C is associated with a [[port-interface]]. The occurrence of an unconnected port is not per se a design mistake. It can be valid when an application provider for the [[data element]] is absent and the default init value is good enough to operate with or it could be that an end point was removed from the [[system]] because it is subjected to variability (See [[Variant Handling]]). == Unconnected Sender/Receiver Ports == If a PPort of a [[Sender Receiver Communication]] is unconnected then the data being published by the provider will not appear on the [[VFB]] and as such will not be accessible by any other software component. If an RPort of a [[Synchronous Sender Receiver Communication]] is unconnected then the RPort shall provide the initial value for the data that is being accessed. For [[Asynchronous Communication]] the [[client]] must behave as if the [[provider]] times out. == Unconnected Client/Server Ports == If a PPort of a [[Client Server Communication]] is not connected the server will not receive any requests. If an RPort of a client server communication is unconnected then the VFB behavior shall be as if the server did not respond in time and the client experiences a [[TIME_OUT]]. 5d92bc6b45e90e8cc0cee98abbd97519b7651fec 0 139 469 151 2013-12-27T21:54:39Z Oliver 1 wikitext text/x-wiki An AUTOSAR Composition encapsulates a collaboration of [[Software Component]]s (SW-C), thereby hiding detail and allowing the creation of higher abstraction levels. Through [[Delegation Connectors]] a Composition explicitly specifies, which [[Port]]s of the internal components are visible from the outside. AUTOSAR Compositions are a type of [[Component]]s, e.g. they can be part of further compositions. The usage of a component-type within a composition is called a [[Prototype]]. bb16715f7eb09339a2be0b5446bf6d6c6a292c5c 470 469 2013-12-27T21:56:49Z Oliver 1 wikitext text/x-wiki An AUTOSAR Composition encapsulates a collaboration of [[Software Component]]s (SW-C), thereby hiding detail and allowing the creation of higher abstraction levels. Through [[Delegation Connectors]] a Composition explicitly specifies, which [[Port]]s of the internal components are visible from the outside. AUTOSAR Compositions are a type of [[Component]]s, e.g. they can be part of further compositions. The usage of a [[Component Type]] within a composition is called a [[Prototype]]. ea708ef9c4a9d7a4daa3b03dd214ceb6edfaacbd 479 470 2013-12-27T22:11:37Z Oliver 1 Redirected page to [[Composition Software Component]] wikitext text/x-wiki #REDIRECT [[Composition Software Component]] fc3695992d4afda0ebcfd77aad864c02432af3d0 0 384 471 2013-12-27T21:57:12Z Oliver 1 Redirected page to [[Component Type]] wikitext text/x-wiki #REDIRECT [[Component Type]] e82e64c46f8f318dadbc4b9502a6a11ccc552d60 0 385 472 2013-12-27T21:58:03Z Oliver 1 Created page with "A component-type is either a [[Composition]] or [[Atomic]]." wikitext text/x-wiki A component-type is either a [[Composition]] or [[Atomic]]. 4628a2daf597c45b398895f0f63d76b7ad424f0a 0 386 473 2013-12-27T21:58:28Z Oliver 1 Created page with "An atomic [[Software Component]] cannot be further decomposed into smaller components." wikitext text/x-wiki An atomic [[Software Component]] cannot be further decomposed into smaller components. b72ced6493c94718c9dc679547b897a8f75dd0ce 0 329 474 384 2013-12-27T22:02:46Z Oliver 1 wikitext text/x-wiki This is an AUTOSAR Interface which is standardized within the AUTOSAR project. AUTOSAR [[Service]]s interact with other [[Software Component]]s through a Standardized AUTOSAR Interface. 8a372edb06e42752214740b16045b957613a1630 0 104 475 109 2013-12-27T22:08:26Z Oliver 1 wikitext text/x-wiki An Application Software Component is a specific [[Software Component]] which realizes a defined functionality on application level (above the [[RTE]]) and runs on the AUTOSAR infrastructure. It communicates only through the AUTOSAR Runtime Environment (RTE). The Application Software Component is an [[Atomic Software Component]] that [[implement]]s (part of) an [[application]]. It can use all [[AUTOSAR communication mechanism]]s and [[service]]s. It interacts with [[sensor]]s or [[actuator]]s through a [[Sensor-Actuator Software Component]]. 8148be1f8e7e097a2d2cc59f8eb58903ede77994 0 387 476 2013-12-27T22:09:09Z Oliver 1 Created page with "The Sensor-Actuator Software Component is an [[Atomic Software Component]] that handles the specifics of a [[sensor]] and/or [[actuator]]. It directly interacts with the [[ECU..." wikitext text/x-wiki The Sensor-Actuator Software Component is an [[Atomic Software Component]] that handles the specifics of a [[sensor]] and/or [[actuator]]. It directly interacts with the [[ECU-Abstraction]] (this is illustrated by a [[port]] called “IO”). bfb86fc01bf2714b9a24eee5a42343f80b24ea51 0 388 478 2013-12-27T22:10:20Z Oliver 1 Created page with "A Parameter Software Component provides parameter values. These can be fixed data, const or variable. This [[Software Component]] allows for data access to either fixed data o..." wikitext text/x-wiki A Parameter Software Component provides parameter values. These can be fixed data, const or variable. This [[Software Component]] allows for data access to either fixed data or [[calibration data]]. e5205e160e61f3c00674890b48eae1d78d96c1ed 0 389 480 2013-12-27T22:12:47Z Oliver 1 Created page with "A Software Composition Component encapsulates a collaboration of [[Software Component]]s (SW-C), thereby hiding detail and allowing the creation of higher abstraction levels. ..." wikitext text/x-wiki A Software Composition Component encapsulates a collaboration of [[Software Component]]s (SW-C), thereby hiding detail and allowing the creation of higher abstraction levels. Through [[Delegation Connectors]] a Composition explicitly specifies, which [[Port]]s of the internal components are visible from the outside. AUTOSAR Compositions are a type of [[Component]]s, e.g. they can be part of further compositions. The usage of a [[Component Type]] within a composition is called a [[Prototype]]. A Composition Software Component encapsulates a collaboration of Software Components, thereby hiding detail and allowing the creation of higher abstraction levels. Through delegation connectors a composition software component explicitly specifies, which ports of the internal components are visible from the outside. Composition Software Components are a specialized type of Software Components, e.g. they can be part of further Composition Software Components. ba72a5acf4cc5d76b5653d91d4020a004f01ad21 0 390 481 2013-12-27T22:14:06Z Oliver 1 Created page with "The Service Proxy [[Software Component]] is responsible for distribution of [[mode]]s throughout the [[system]]. Once deployed each [[ECU]] should have a copy of every instanc..." wikitext text/x-wiki The Service Proxy [[Software Component]] is responsible for distribution of [[mode]]s throughout the [[system]]. Once deployed each [[ECU]] should have a copy of every instance of this [[software component type]]. However at the [[VFB]] level only one is necessary. 16c6cddc0730a48cb4ac3a19c6fd0eb92a6fec88 0 391 482 2013-12-27T22:15:01Z Oliver 1 Redirected page to [[Service Proxy Software Component]] wikitext text/x-wiki #REDIRECT [[Service Proxy Software Component]] 093489c87a369aba3e65da41ad244a69df96e728 0 392 483 2013-12-27T22:16:04Z Oliver 1 Created page with "A Service [[Software Component]] provides standardized [[service]]s through [[Standardized Interface]]s. To provide these services, this component may interact directly with c..." wikitext text/x-wiki A Service [[Software Component]] provides standardized [[service]]s through [[Standardized Interface]]s. To provide these services, this component may interact directly with certain other [[basic-software module]]s. c6bdade504b224ec2ce2bfb202d2305aecac10c4 0 393 484 2013-12-27T22:17:18Z Oliver 1 Created page with "The ECU-Abstraction [[Software Component]] provides access to the [[ECU]]’s specific [[IO]] capabilities. These services are typically provided through client-server [[PPort..." wikitext text/x-wiki The ECU-Abstraction [[Software Component]] provides access to the [[ECU]]’s specific [[IO]] capabilities. These services are typically provided through client-server [[PPort]]s and are used by the [[sensor-actuator software component]]s. The ECU-abstraction may directly interact with certain other [[basic-software module]]s. bcf485e00a0e989a8378e0fd1b07ede67f0f3f83 0 30 485 450 2013-12-27T22:17:51Z Oliver 1 Redirected page to [[Complex Device Driver Software Component]] wikitext text/x-wiki #REDIRECT [[Complex Device Driver Software Component]] 4a208f77271596d75a0e601b0eb996a2eb181a0a 0 394 486 2013-12-27T22:18:04Z Oliver 1 Redirected page to [[Complex Device Driver Software Component]] wikitext text/x-wiki #REDIRECT [[Complex Device Driver Software Component]] 4a208f77271596d75a0e601b0eb996a2eb181a0a 0 395 487 2013-12-27T22:18:56Z Oliver 1 Created page with "The Complex Device Driver [[Software Component]] generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with other components in specific ways and ..." wikitext text/x-wiki The Complex Device Driver [[Software Component]] generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with other components in specific ways and can also interact directly with other [[basic-software module]]s. 9c552c94a7a7eac5a39a68268836e8c88063a729 0 396 488 2013-12-27T22:20:17Z Oliver 1 Created page with "The NV Block [[Software Component]] allows SW-Cs access to [[non volatile data]]. Specifically this block allows for the modeling of the NV data at the [[VFB]] level. It is th..." wikitext text/x-wiki The NV Block [[Software Component]] allows SW-Cs access to [[non volatile data]]. Specifically this block allows for the modeling of the NV data at the [[VFB]] level. It is the responsibility of the [[NV Block]] to map individual [[NV data element]]s to NV Blocks and to interact with the [[NV Manager]] in the [[BSW]]. The behavior of this component is to be generated based on the [[port service]]s in the [[RTE]]. 32bef8f7004983d1c821421535619f10816e2339 0 397 489 2013-12-27T23:41:13Z Oliver 1 Redirected page to [[Runnable entity]] wikitext text/x-wiki #REDIRECT [[Runnable entity]] 37996d4f9981f0834bdce1c844b8fee2d1a661df 0 398 491 2014-04-15T21:34:03Z 192.168.2.119 0 Created page with "Method Library Elements comprise: -[[Task Definition]] -[[Work Product Definition]] -[[Role Definition]] -[[Tool Definition]] -[[Guidance]]" wikitext text/x-wiki Method Library Elements comprise: -[[Task Definition]] -[[Work Product Definition]] -[[Role Definition]] -[[Tool Definition]] -[[Guidance]] d269a3886292ec06554d2cfa498c61c43e9be4ec 493 491 2014-04-15T21:40:24Z Oliver 1 wikitext text/x-wiki Method Library Elements comprise: -[[Task]] -[[Work Product]] -[[Role]] -[[Tool]] -[[Guidance]] 33e43e12618553b1c3d9f97dd1496580bbd500bd 503 493 2014-04-16T14:40:50Z Oliver 1 wikitext text/x-wiki Method Library Elements comprise: -[[Task]] -[[Work Product]] -[[Role]] -[[Tool]] -[[Guidance]] -[[Table]]s eaec2a94bfed8af9ddb51c6bf156873fbdf2c9b5 504 503 2014-04-16T14:43:11Z Oliver 1 wikitext text/x-wiki Method Library Elements comprise: -[[Task]] -[[Work Product]] -[[Role]] -[[Tool]] -[[Guidance]] 33e43e12618553b1c3d9f97dd1496580bbd500bd 0 400 494 2014-04-15T21:43:04Z Oliver 1 Created page with "According to the [[SPEM]] [[meta model]], a Work Product Definition is used, modified, and produced by [[Task]]s (i.e. a task input and output). Work Products are in most case..." wikitext text/x-wiki According to the [[SPEM]] [[meta model]], a Work Product Definition is used, modified, and produced by [[Task]]s (i.e. a task input and output). Work Products are in most cases tangible work products consumed, produced, or modified by Tasks. They may serve as a basis for defining reusable assets. A Work Product can be related to other work products by a kind of nesting relationship. [[Role]]s use Work Products to perform Tasks and produce Work Products in the course of performing the Tasks. Work Products are in the responsibility of the associated Roles, thereby also defining a set of skills the performing Role should have. Even though one Role might own a specific type of Work Product, other Roles can still use the Work Product for their work, and update them. A Work Product can be of type - [[Artifact]] - [[Deliverable]] db8acbe3adfd744e63e87d159d062dc2c025663f 0 339 495 395 2014-04-16T09:34:46Z Oliver 1 wikitext text/x-wiki == OS == A Task is the smallest schedulable unit managed by the [[OS]]. The OS decides when which task can run on the [[CPU]] of the [[ECU]]. A [[runnable entity]] of a [[software component]] runs in the context of a task. Also the [[Basic Software Module]]s runs in the context of a task. == Methodology == According to the [[SPEM]] [[meta model]], a Task Definition is an assignable unit of work that is being performed by specific [[Role]]s. The duration of a task is generally a few hours to a few days. Tasks usually generate one or more [[work product]]s. Each Task is associated to input and output [[Work Product]]s. Inputs are differentiated in mandatory and optional inputs. A Task is used as one element among others to define a [[Process]]. A Task has a clear purpose in which the performing roles achieve a well defined goal. It provides complete step-by-step explanations of doing all the work that needs to be done to achieve this goal. This description is completely independent of when in a process lifecycle the work would actually be done. It does not describe when what work is being done, but describes all the work that gets done. When a Task is used in a process ([[Task Use]]), it provides the information of which pieces of the Task will actually be performed at any particular point in time. This assumes that the Task will be performed in the process over and over again, but each time with a slightly different emphasis on different steps or aspects of the task description. For the [[AUTOSAR Methodology]], a Task is a reusable element that is used across multiple methodology use cases. A Task is associated to at least one performing Role and may have several additional performers. Tasks use Tools to achieve their outputs. Optional performers and optional input and outputs to the task are described by the relationship’s multiplicity. 2c35b4a5521eb4375d398cd411fe88aceae5b36c 0 106 496 111 2014-04-16T09:39:01Z Oliver 1 wikitext text/x-wiki This is a [[Work Product]] Definition that provides a description and definition for tangible work product types. Artifacts may be composed of other artifacts. At a high level, an artifact is represented as a single conceptual file. A tangible [[Work Product]] that is consumed, produced, or modified by one or more [[Task]]s. Artifacts may be composed of other Artifacts and may serve as a basis for defining reusable asset. For the [[AUTOSAR Methodology]], typical kinds of artifacts are: – AUTOSAR XML – source code – binary code (executable) – text At a high level, an artifact is represented as a single conceptual file. As a rule of thumb, the AUTOSAR Methodology will use artifacts that have most of the following properties: – Separate versioning is needed – A dedicated [[life cycle]] has to be cared for – Different exchange requirements need to be fulfilled – Change in responsible [[role]]s – Change in multiplicities – Change is physical representation or format – One of the products may be a separate deliverable to another party – Separation of standardized from non-standardized parts To express a relationship between artifacts of the methodology model and any [[AUTOSAR metamodel]] element, a relationship with the stereotype «atpUseMetaModelElement» is used to express this ”dependency”. For AUTOSAR metamodel elements that are not directly related to methodology elements, there is usually an indirect relationship via a related metamodel element. The methodology can thus focus on the main elements of the metamodel. 9b3bf1d2bd6100b809e1f27b8d9fd17b4ed59ec5 0 401 497 2014-04-16T09:41:13Z Oliver 1 Created page with "Used to pre-define typical or recommended content in the form of [[Work Product]]s that would be packaged for delivery. Deliverables are used to represent an output from a pro..." wikitext text/x-wiki Used to pre-define typical or recommended content in the form of [[Work Product]]s that would be packaged for delivery. Deliverables are used to represent an output from a process that has value, material or otherwise, to a client, customer, or other stakeholder. A Deliverable is a Work Product that aggregates other Work Products. The Method Content maintains preconfigured potential Deliverables. For the [[AUTOSAR Methodology]], the aggregation relationship is used to indicate which Work Products are contained in a deliverable. 4956f54556ba7dcd7c05c6ae243003244eb6d134 0 102 498 106 2014-04-16T09:42:54Z Oliver 1 wikitext text/x-wiki This is an organization, which employs or contracts individual [[assessor]]s, who in turn perform the [[independent assessment]]s as part of the [[accreditation]] process. In the AUTOSAR context the Accreditation Bodies have the [[role]] to accredit the [[Conformance Test Agencies]]. 74324d83d66c7d8bfd8369dd1830804e23c13a2a 0 33 499 156 2014-04-16T09:43:12Z Oliver 1 wikitext text/x-wiki Conformance Test Agency This is an organization performing a [[role]] with specific tasks in the conformance test process. Two possibilities are distinguished, a [[third party]] CTA or a [[first party]] CTA (which is also a product supplier). The tasks/services provided by a CTA is: - Provision of a [[CTS]] - Test execution - Attestation of product conformance For a third party CTA the focus is on the attestation and for a first party the focus is on the test execution. 18cb6e11d8bd8b2c1787881b3f406eb28136c610 0 402 500 2014-04-16T09:44:57Z Oliver 1 Created page with "According to the [[SPEM meta model]], Role Definitions define responsibilities of an individual or a set of individuals and thereby define a set of related skills, competencie..." wikitext text/x-wiki According to the [[SPEM meta model]], Role Definitions define responsibilities of an individual or a set of individuals and thereby define a set of related skills, competencies, and qualifications needed to perform a [[Task]]. A Role can be filled by one person or multiple people, one person may fill several Roles. Each Role performs Tasks. Roles are not individuals or resources. Individual members of the development organization will wear different hats, or perform different Roles. The mapping from individual to Role, usually performed by the project manager when planning and staffing a project, allows different individuals to act as several different Roles, and for a Role to be taken by several individuals. In the [[AUTOSAR Methodology]], a Role also assigns the responsibility of a Task and defines optional performers. Performers that are responsible for e.g. a Task have a multiplicity of 1 for the relationship to the Task, optional performers have optional multiplicity assigned. Role Definitions are usually generic and still provide sufficient level of detail for managers to organize a team. Examples of Roles are ”System Engieer”, ”Safety Engineer”, or ”Software Developer”. e391af6dad2933c866a4693d24fa49434f0d2f62 0 403 501 2014-04-16T14:25:47Z Oliver 1 Created page with "According to the [[SPEM meta model]], Tool Definitions can be used to specify a tool’s participation in a [[Task]]. A Tool Definition describes the capabilities of a [[CASE ..." wikitext text/x-wiki According to the [[SPEM meta model]], Tool Definitions can be used to specify a tool’s participation in a [[Task]]. A Tool Definition describes the capabilities of a [[CASE tool]], general purpose tool, or any other automation unit that supports the associated [[Role]]s in performing the work defined by a Task. A Tool can identify a resource as useful, recommended, or necessary for a task’s completion. A Tool can also be used to manage one or more Work Products. The [[AUTOSAR Methodology]] uses the Tool Definition to describe AUTOSAR specific (e.g. [[Software Component]] Contract [[Generator]]) and other general Tools (e.g. Compilers). The relationship of a Tool to a Task shows which Tools a Role will need to perform the Task. 16c4f7c5250ec8825c664f721e762d4884e1a825 0 404 502 2014-04-16T14:31:01Z Oliver 1 Created page with "According to the [[SPEM meta model]], a Guidance provides additional information related to e.g. [[Role]]s, [[Work Product]]s, and [[Task]]s. A Guidance is classified to indic..." wikitext text/x-wiki According to the [[SPEM meta model]], a Guidance provides additional information related to e.g. [[Role]]s, [[Work Product]]s, and [[Task]]s. A Guidance is classified to indicate a specific type for which perhaps a specific structure and type of content is assumed. A Guidance can be a '''Supporting Material''' is a catch-all for other types of guidance not specifically defined elsewhere. It can be related to all kinds of Content [[Element]]s, i.e., including other guidance elements. The [[AUTOSAR Methodology]] uses the Supporting Material Guidance type to define title pages, change histories, disclaimers etc. A '''Tool Mentor''' shows how to use a specific [[Tool]] to accomplish some piece of work either in the context of or independent from a Task or [[Activity]]. In the context of the AUTOSAR Methodology, a Tool Mentor is used in the same way as the [[Tool element]]. '''White Papers''' are concept guidances that have been externally reviewed or published and can be read and understood in isolation from other Method Content. AUTOSAR documents are examples of White Papers. Other Guidances such as Checklists, Concepts, Estimates, Guidelines, Practices, Reports, Reusable Assets, Roadmaps, or Templates are not used within the AUTOSAR Methodology. 938e6a806e99eda8e90d9d2edce85d851006cbf4 0 405 505 2014-04-16T20:12:35Z Oliver 1 Created page with "A Capability Pattern is a process pattern that contains a reusable set of activities. Capability Patterns can be assembled to larger Capability Patterns that describe developm..." wikitext text/x-wiki A Capability Pattern is a process pattern that contains a reusable set of activities. Capability Patterns can be assembled to larger Capability Patterns that describe development processes or parts of a development process including typical use cases. c4f8df427eb441a2669b17070a0c97034ab1b529 0 354 506 412 2014-04-16T20:15:17Z Oliver 1 wikitext text/x-wiki Confirmation by examination and provisions of objective evidence that specified requirements have been fulfilled. In design and development, verification concerns the process of examining the result of a given [[activity]] to determine conformity with the stated requirement for that activity. “Verified” is used to designate the corresponding status. [ISO 8402: 1994] 03073dbf88a49b59448bfde2d848a1938f947460 0 214 507 247 2014-04-16T20:15:30Z Oliver 1 wikitext text/x-wiki 1. A [[task]], action or [[activity]] that must be accomplished to achieve a desired outcome. 2. A part of programming code that is invoked by other parts of the program to fulfill a desired purpose. 3. In mathematics, a function is an association between two sets of values in which each element of one set has one assigned element in the other set so that any element selected becomes the independent variable and its associated element is the dependent variable. Due to the different meanings in texts using the term application the appropriate meaning should be explained in detail or referenced. b141599017f7e1d2b2c45150a28f99ea3ace4ac2 0 158 508 176 2014-04-16T20:15:50Z Oliver 1 wikitext text/x-wiki Output of the [[ECU Configuration]] activity containing the values of configuration parameters and references. [[ECU]] Configuration Description holds the configuration parameter values and references to other [[module]]'s configurations which have been defined in the ECU Configuration [[activity]]. ECU Configuration Description may contain the whole ECU Configuration information or only the parts relevant for a specific configuration step (e.g. [[Pre-compile time]]). 39e3dcef8158f18d65d8e9e41065e865696d01e6 0 157 509 175 2014-04-16T20:16:01Z Oliver 1 wikitext text/x-wiki [[Activity]] of integrating and configuring one [[ECU]]’s software. Further Explanations: ECU Configuration denotes the activity when one ECU's software is set up for a specific usage inside the ECU. In AUTOSAR the ECU Configuration activity is divided into [[Pre-compile time]], [[Link time]] and [[Post-build time]] configuration. b7b6328d49486022591b0fbe5fe55c41aa793616 0 107 510 112 2014-04-16T20:16:12Z Oliver 1 wikitext text/x-wiki [[Activity]] conducted by an [[assessor]] to demonstrate that the assessed organization fulfills the set requirements. Within the AUTOSAR context after the initial assessment a new full-set assessment will be repeated every 4 years. In between, [[surveillances]] take place once a year. 8d35f6ce87c074aa3f2c2d9ce2a5fa5fee7eb039 0 406 511 2014-04-16T20:18:49Z Oliver 1 Created page with "In the [[SPEM meta model]], an Activity is the main building block to define a [[process]]. An Activity is usually a defined [[task]] or work to be done that is commonly execu..." wikitext text/x-wiki In the [[SPEM meta model]], an Activity is the main building block to define a [[process]]. An Activity is usually a defined [[task]] or work to be done that is commonly executed in one sequence. Activities can include other Activities and thereby often decompose a flow of work and show which Activity precedes other Activities. At the lowest level, Activities are collections of work breakdown elements which in [[AUTOSAR Methodology]] are [[task]]s , [[role]]s , and [[work product]]s. A Process is a special Activity in the SPEM meta model that describes a typical structure of development projects or parts of them. A Process focuses on the lifecycle and the sequencing of work in [[breakdown structure]]s. [[Process]]es contain sequences of Task and Activities and thereby express a [[lifecycle]] of the product under development. Processes also define how to get from one [[milestone]] to the next by defining sequences of work, [[operation]]s, or [[event]]s. 18abf6e9a17ee3b884cf672c89ecdead88c2e62f 0 407 512 2014-04-16T20:58:31Z Oliver 1 Created page with "Software Process Engineering Meta-Model Specification [http://www.omg.org/spec/SPEM/2.0/]" wikitext text/x-wiki Software Process Engineering Meta-Model Specification [http://www.omg.org/spec/SPEM/2.0/] dcd1cfe4aa45010b34b07bd28196a3991f729d58 0 408 513 2014-04-17T09:44:07Z Oliver 1 Created page with "The System Extract is not fully decomposed and still needs to be refined before it forms the basis for the [[ECU configuration]]. [[Atomic Software Components]], additional [[..." wikitext text/x-wiki The System Extract is not fully decomposed and still needs to be refined before it forms the basis for the [[ECU configuration]]. [[Atomic Software Components]], additional [[ECU]]s, Networks and the resulting communication will be added during the refinement step in the activity Design Subsystem. 844f7d2aec2c5196aeb839c7200c762ae66c6dc0 523 513 2014-04-17T09:51:12Z Oliver 1 wikitext text/x-wiki The System Extract ([[arxml]] file) is not fully decomposed and still needs to be refined before it forms the basis for the [[ECU configuration]]. [[Atomic Software Components]], additional [[ECU]]s, [[Network]]s and the resulting communication will be added during the refinement step in the activity Design Subsystem. b78b1e60a76e0d88277eec88c8e2f8b11dd0f99f 524 523 2014-04-17T09:53:54Z Oliver 1 wikitext text/x-wiki The System Extract ([[arxml]] file) is an extract of the [[System Description]] for a specific [[sub-system]]. It is not fully decomposed and still needs to be refined before it forms the basis for the [[ECU configuration]]. [[Atomic Software Components]], additional [[ECU]]s, [[Network]]s and the resulting communication will be added during the refinement step in the activity Design Subsystem. The System Extract is a basis to develop a sub-system. ff4e1a36b63c54a64ede448822c00c174279048e 525 524 2014-04-17T09:55:17Z Oliver 1 wikitext text/x-wiki The System Extract ([[arxml]] file) is an extract of the [[System Description]] for a specific [[subsystem]]. It is not fully decomposed and still needs to be refined before it forms the basis for the [[ECU configuration]]. [[Atomic Software Components]], additional [[ECU]]s, [[Network]]s and the resulting communication will be added during the refinement step in the activity Design Subsystem. The System Extract is a basis to develop a subsystem. Generating the System Extract means to reduce the content of the input description to the subsystem in question. 2e9668f1f83ae16a86c89f78f427e7cd8790da58 0 320 515 444 2014-04-17T09:45:19Z Oliver 1 wikitext text/x-wiki Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Functional Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the [[software component template]]. Software Components can be abbreviated as SW-Cs. 3369453be51270a506b1f2d851e0420733da2f41 516 515 2014-04-17T09:45:40Z Oliver 1 wikitext text/x-wiki Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Functional Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the [[software component]] [[template]]. Software Components can be abbreviated as SW-Cs. 64bda0d77fbebed4e925c757d3d0b9ca84503c84 517 516 2014-04-17T09:46:18Z Oliver 1 wikitext text/x-wiki Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Functional Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the [[Software Component]] [[template]]. Software Components can be abbreviated as SW-Cs. 335c81a5c7ed0b180237af8ad8830664ef223b06 518 517 2014-04-17T09:47:03Z Oliver 1 wikitext text/x-wiki Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Functional Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the [[Software Component]] template. Software Components can be abbreviated as SW-Cs. ea006e0e52cfa89f735f595b9a12ba5f60a27b84 519 518 2014-04-17T09:47:39Z Oliver 1 wikitext text/x-wiki Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Functional Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the [[software component]] template. Software Components can be abbreviated as SW-Cs. c9698fdc50e90c0d53646dd052e3f46e598e8c7b 521 519 2014-04-17T09:48:25Z Oliver 1 wikitext text/x-wiki Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Functional Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the Software Component [[template]]. Software Components can be abbreviated as SW-Cs. d10f60cccafff541823d675c6d470f98ef6d833d 535 521 2014-07-22T21:30:14Z 192.168.2.119 0 wikitext text/x-wiki Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Functional Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the Software Component [[template]]. Software Components can be abbreviated as SW-Cs. A SW-C contains a [[Software Component Description]] (SWCD) and the [[implementation]]. 9786ee26462084be048bc1fa91a2655d73d8df63 0 410 520 2014-04-17T09:47:50Z Oliver 1 Redirected page to [[Software Component]] wikitext text/x-wiki #REDIRECT [[Software Component]] 1b400e021eae68abe0c8a724614f9c7de4209b9a 0 411 522 2014-04-17T09:50:38Z Oliver 1 Created page with "The [[System Configuration Description]] is used as a basis to generate ECU Extracts ([[arxml]] file) which directly contain all relevant information to be integrated on an [[..." wikitext text/x-wiki The [[System Configuration Description]] is used as a basis to generate ECU Extracts ([[arxml]] file) which directly contain all relevant information to be integrated on an [[ECU]]. 6eebaf9a0d4660a2b2980efb2e3cb0725205b201 526 522 2014-04-17T11:14:19Z Oliver 1 wikitext text/x-wiki The [[System Configuration Description]] is used as a basis to generate ECU Extracts ([[arxml]] file) which directly contain all relevant information to be integrated on an [[ECU]]. The ECU Extract is the basis for setting up the ECU configuration and further development on ECU level. 40525d8d7e2083249a8a641b4b6f2bd0bccdbea3 0 412 527 2014-07-07T20:17:18Z 192.168.2.119 0 Created page with "In a design step called “Configure System”, the [[SWC|components]] are mapped on specific system resources ([[ECU]]s). Thereby, the [[virtual connection]]s between the com..." wikitext text/x-wiki In a design step called “Configure System”, the [[SWC|components]] are mapped on specific system resources ([[ECU]]s). Thereby, the [[virtual connection]]s between the components are mapped onto local connections (within a single ECU) or on network-technology specific communication mechanisms (such as [[CAN]] or [[FlexRay]] frames). The [[VFB]] can be used for plausibility checks concerning the communication of software components. 8c7950b3d4d7a0b50ab3dcfee5b475d428da3169 0 413 528 2014-07-07T20:18:22Z 192.168.2.119 0 Created page with "AUTOSAR supports multiple instantiation of [[SWC|component]]s. This means that there can be several instances of the same component in a vehicle system. These components will ..." wikitext text/x-wiki AUTOSAR supports multiple instantiation of [[SWC|component]]s. This means that there can be several instances of the same component in a vehicle system. These components will typically have their own separate internal state (stored in separate memory locations) but might for example share the same code (in as far as the code is appropriately written to support this). ec39655377bf0ae8f0a289b8671b3c9946e0549b 0 414 529 2014-07-22T21:21:36Z 192.168.2.119 0 Created page with "The Runtime Environment implements the [[VFB]] functionality on a specific [[ECU]]." wikitext text/x-wiki The Runtime Environment implements the [[VFB]] functionality on a specific [[ECU]]. fda9d433769da75ca65347dd1da4ec68b1d3a84f 0 415 530 2014-07-22T21:23:26Z 192.168.2.119 0 Created page with "Communication which is [[ECU]] internally (within the ECU boundary)." wikitext text/x-wiki Communication which is [[ECU]] internally (within the ECU boundary). 43fee28d5d2f0897b1edb01e3e94066580c5165d 0 416 531 2014-07-22T21:24:36Z 192.168.2.119 0 Created page with "Communication between two or more [[ECU]]s (e.g. via external bus like [[CAN]], [[FlexRay]], etc.)." wikitext text/x-wiki Communication between two or more [[ECU]]s (e.g. via external bus like [[CAN]], [[FlexRay]], etc.). 6c915fa8ad4a62a557f32443b3c39b6dae1a7eac 0 417 532 2014-07-22T21:26:42Z 192.168.2.119 0 Created page with "The Software Component Description (SWCD) defines all properties of a [[Software Component]]. This could be done by [[ARtext]] language description, or with some Software Tool." wikitext text/x-wiki The Software Component Description (SWCD) defines all properties of a [[Software Component]]. This could be done by [[ARtext]] language description, or with some Software Tool. 8ba445e531e1842d6186aeb74f6f1a86a2aa7392 534 532 2014-07-22T21:28:45Z 192.168.2.119 0 wikitext text/x-wiki The Software Component Description (SWCD) defines all properties of a [[Software Component]] like [[port]]s, [[interface]]s, [[behavior]]. This could be done by [[ARtext]] language description, or with some Software Tool. 5f470b9803cd5b6329328bdad433a90b94f51cbf 538 534 2014-07-22T21:33:46Z 192.168.2.119 0 Blanked the page wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 539 538 2014-07-22T21:34:29Z 192.168.2.119 0 Redirected page to [[Software Component Description]] wikitext text/x-wiki #REDIRECT [[Software Component Description]] db658b5a3e222778e64e79ed410077f334787899 0 418 533 2014-07-22T21:27:32Z 192.168.2.119 0 Redirected page to [[Software component description]] wikitext text/x-wiki #REDIRECT [[Software component description]] dae6cd230d4c8bf3619d805625231f18ba460601 536 533 2014-07-22T21:32:32Z 192.168.2.119 0 Redirected page to [[Software Component Description]] wikitext text/x-wiki #REDIRECT [[Software Component Description]] db658b5a3e222778e64e79ed410077f334787899 0 419 537 2014-07-22T21:33:17Z 192.168.2.119 0 Created page with "The Software Component Description (SWCD) defines all properties of a [[Software Component]] like [[port]]s, [[interface]]s, [[behavior]]. This could be done by [[ARtext]] lan..." wikitext text/x-wiki The Software Component Description (SWCD) defines all properties of a [[Software Component]] like [[port]]s, [[interface]]s, [[behavior]]. This could be done by [[ARtext]] language description, or with some Software Tool. 5f470b9803cd5b6329328bdad433a90b94f51cbf 0 421 542 2014-07-22T21:38:07Z 192.168.2.119 0 Created page with "Array or Record" wikitext text/x-wiki Array or Record 6d7f3bb28c0716af4ecbc0f0f043c56be780687e 0 422 543 2014-07-22T21:45:45Z 192.168.2.119 0 Created page with "Operations are functions defined by the [[interface]] of a [[Client-Server Port]]. Each operation can contain arguments of type IN, OUT or IN/OUT. Each operation can return ..." wikitext text/x-wiki Operations are functions defined by the [[interface]] of a [[Client-Server Port]]. Each operation can contain arguments of type IN, OUT or IN/OUT. Each operation can return [[Error Return Code]]s. d6c151320f7a7c078dc96b1588ffaef079bbeca2 0 423 544 2014-07-22T21:46:11Z 192.168.2.119 0 Redirected page to [[Client-Server Interface]] wikitext text/x-wiki #REDIRECT [[Client-Server Interface]] 74567c4a38b0c74600a1e2dd36b0a7d7c3342559 0 424 545 2014-07-22T21:46:57Z 192.168.2.119 0 Redirected page to [[Client-Server Port]] wikitext text/x-wiki #REDIRECT [[Client-Server Port]] 1fdbd9a5cbf14848e389a559511a8da79d514fe9 0 425 546 2014-07-22T21:58:56Z 192.168.2.119 0 Redirected page to [[Software Requirement Specification]] wikitext text/x-wiki #REDIRECT [[Software Requirement Specification]] 721b1047b6ee74a8b11ded7215630073cd7ae2cf 0 426 547 2014-07-23T07:43:02Z 192.168.2.119 0 Created page with "The communication matrix is defining the [[message]]s/[[signal]] sent and received by each participating [[node]]. It could be defined in a fibex-file ([[FlexRay]]), CANdb-fil..." wikitext text/x-wiki The communication matrix is defining the [[message]]s/[[signal]] sent and received by each participating [[node]]. It could be defined in a fibex-file ([[FlexRay]]), CANdb-file ([[CAN]]) or AUTOSAR [[arxml]]-file. 9600588441b33dfa1861d49212ae327ba34a5666 0 427 548 2014-07-23T07:43:30Z 192.168.2.119 0 Redirected page to [[Communication Matrix]] wikitext text/x-wiki #REDIRECT [[Communication Matrix]] 3c88dafeb641f61df36dbb9cb5e10b4b3fd15862 0 428 549 2014-07-23T07:43:45Z 192.168.2.119 0 Redirected page to [[Communication Matrix]] wikitext text/x-wiki #REDIRECT [[Communication Matrix]] 3c88dafeb641f61df36dbb9cb5e10b4b3fd15862 0 429 550 2014-07-23T07:43:58Z 192.168.2.119 0 Redirected page to [[Communication Matrix]] wikitext text/x-wiki #REDIRECT [[Communication Matrix]] 3c88dafeb641f61df36dbb9cb5e10b4b3fd15862 0 430 551 2014-07-23T07:44:55Z 192.168.2.119 0 Redirected page to [[SOP]] wikitext text/x-wiki #REDIRECT [[SOP]] 9afc8dd657829ae4c79a91e0ae2832d71b85f01b 0 431 552 2014-07-23T07:46:19Z 192.168.2.119 0 Created page with "Start Of Production (SOP, also Job1 or Job #1) is the milestone when the [[OEM]] starts with building the vehicles." wikitext text/x-wiki Start Of Production (SOP, also Job1 or Job #1) is the milestone when the [[OEM]] starts with building the vehicles. 5919c3253b98cd4d981679df635bbf65a37a6572 0 337 553 393 2014-07-23T07:49:55Z 192.168.2.119 0 wikitext text/x-wiki Boundary conditions that restrict the Design-Freedom of the (cars E/E-) [[System]]. The design of [[ECU Network]]s and the distribution of functionalities to [[ECU]]s are limited by several constrains. These constraints result mostly by the [[Communication Matrix]] and safety requirements. 02140bb4a2ae81c90a8581ae1d6105193974fed1 0 432 554 2014-07-23T07:52:18Z 192.168.2.119 0 Created page with "Service needs are defined for a specific [[SW-C]] in the [[Software Component Description]] (SWCD). It defines the [[service interface]]s needed from the [[BSWM]]." wikitext text/x-wiki Service needs are defined for a specific [[SW-C]] in the [[Software Component Description]] (SWCD). It defines the [[service interface]]s needed from the [[BSWM]]. 89ab355cf497c5a830dc974eb50660372b932232 0 433 555 2014-07-23T07:52:30Z 192.168.2.119 0 Created page with "The Contract Phase are the files generated by the [[RTE-Generator]] for [[SW-C]] independent of the [[BSWM]]. It is used to enable the SW-C supplier to start implementing code..." wikitext text/x-wiki The Contract Phase are the files generated by the [[RTE-Generator]] for [[SW-C]] independent of the [[BSWM]]. It is used to enable the SW-C supplier to start implementing code even before the BSWM are configured. The Contract Phase also defines the [[service needs]] etc. of the specific SW-C. ffcf90786b342764773dadece81518582bfa370a 0 434 556 2014-07-23T07:53:47Z 192.168.2.119 0 Redirected page to [[Basic Software Module Description]] wikitext text/x-wiki #REDIRECT [[Basic Software Module Description]] 800509e9504e6e1a37984a3a63447afd7f7dcd55 0 317 557 413 2014-07-23T09:12:56Z 192.168.2.119 0 wikitext text/x-wiki A Service Port is a [[Port]] of an [[SW-C]], [[Complex Device Driver]] (CDD) and/or [[ECU Abstraction]] connected to an AUTOSAR [[Service]]. The [[interface]] of a Service Port has to be a Standardized [[AUTOSAR Interface]]. A Service Port does not need to be connected to another Port in the [[VFB View]]. 6a57821b876b2788411dd41100a3ac2e64c353f7 0 112 558 118 2014-07-23T09:13:59Z 192.168.2.119 0 wikitext text/x-wiki The AUTOSAR Interface of a software component ([[SW-C]]) refers to the collection of all [[port]]s of that component through which it interacts with other components. 0104d9b82d4506d70c150fabab00c3040aaeaa69 0 275 559 468 2014-07-24T06:45:56Z 192.168.2.119 0 wikitext text/x-wiki A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[Provide Port]] (p-port, PPort) or a [[Receive Port]] (r-port, RPort). A port of a SW-C is associated with a [[port-interface]]. The occurrence of an unconnected port is not per se a design mistake. It can be valid when an application provider for the [[data element]] is absent and the default init value is good enough to operate with or it could be that an end point was removed from the [[system]] because it is subjected to variability (See [[Variant Handling]]). == Unconnected Sender Ports == Data of the sender will not appear on VFB. Generated RTE might simply call empty function or even optimize function call to zero code. == Unconnected Synchronous Receiver Ports == The RPort will always read the initial value specified for this RPort. == Unconnected Asynchronous Receiver Ports == The RPort will receive a time-out like the Sender is not providing data. == Unconnected Server Ports == The operations (functions) of the PPort interface will never be called. Generated RTE (or finally the compiler) might even optimize operation to zero code. == Unconnected Client Ports == According to AUTOSAR specification the [[operation]]s (functions) on the RPort will TIME_OUT. But more likely the [[RTE-Generator]] will generate a return code RTE_E_UNCONNECTED for any unconnected [[client]] interface operation. 9bedb2fc16ba236d510f2c8411aa4905261c340f 560 559 2014-07-24T06:46:41Z 192.168.2.119 0 wikitext text/x-wiki A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[Provide Port]] (p-port, PPort) or a [[Require Port]] (r-port, RPort). A port of a SW-C is associated with a [[port-interface]]. The occurrence of an unconnected port is not per se a design mistake. It can be valid when an application provider for the [[data element]] is absent and the default init value is good enough to operate with or it could be that an end point was removed from the [[system]] because it is subjected to variability (See [[Variant Handling]]). == Unconnected Sender Ports == Data of the sender will not appear on VFB. Generated RTE might simply call empty function or even optimize function call to zero code. == Unconnected Synchronous Receiver Ports == The RPort will always read the initial value specified for this RPort. == Unconnected Asynchronous Receiver Ports == The RPort will receive a time-out like the Sender is not providing data. == Unconnected Server Ports == The operations (functions) of the PPort interface will never be called. Generated RTE (or finally the compiler) might even optimize operation to zero code. == Unconnected Client Ports == According to AUTOSAR specification the [[operation]]s (functions) on the RPort will TIME_OUT. But more likely the [[RTE-Generator]] will generate a return code RTE_E_UNCONNECTED for any unconnected [[client]] interface operation. 9a72841dce729593f85afbd61691f30d76b13eec 0 435 561 2014-07-24T10:19:00Z 192.168.2.119 0 Created page with "The Standard Types are defined in file Std_Types.h == The following types are specified == === Std_ReturnType === This type can be used as standard [[API]] return type whi..." wikitext text/x-wiki The Standard Types are defined in file Std_Types.h == The following types are specified == === Std_ReturnType === This type can be used as standard [[API]] return type which is shared between the [[RTE]] and the [[BSW]] modules. typedef uint8 Std_ReturnType; Range: E_OK, E_NOT_OK, 0x02-0x3F (user specific errors), Bit 7 and Bit 8 are reserved. === Std_VersionInfoType === This type shall be used to request the version of a [[BSW]] module using the <Module name>_GetVersionInfo()function. <code> typedef struct { uint16 vendorID; uint16 moduleID; uint8 sw_major_version; uint8 sw_minor_version; uint8 sw_patch_version; } Std_VersionInfoType; </code> == The following types are specified == === E_OK, E_NOT_OK === <tt> E_OK := 0x00 E_NOT_OK := 0x01 </tt> === STD_HIGH, STD_LOW === <tt> STD_HIGH := 0x00 STD_LOW := 0x01 </tt> === STD_ACTIVE, STD_IDLE === <tt> STD_ACTIVE := 0x00 STD_IDLE := 0x01 </tt> === STD_ON, STD_OFF === <tt> STD_ON := 0x00 STD_OFF := 0x01 </tt> 0abfe0f1376fd90b450dd81a79dd5ac998a6d1e1 572 561 2014-07-24T10:25:10Z 192.168.2.119 0 wikitext text/x-wiki The Standard Types are defined in file Std_Types.h == The following types are specified == === Std_ReturnType === This type can be used as standard [[API]] return type which is shared between the [[RTE]] and the [[BSW]] modules. typedef uint8 Std_ReturnType; Range: E_OK, E_NOT_OK, 0x02-0x3F (user specific errors), Bit 7 and Bit 8 are reserved. === Std_VersionInfoType === This type shall be used to request the version of a [[BSW]] module using the <Module name>_GetVersionInfo()function. <code> typedef struct { uint16 vendorID; uint16 moduleID; uint8 sw_major_version; uint8 sw_minor_version; uint8 sw_patch_version; } Std_VersionInfoType; </code> == The following symbols are specified == === E_OK, E_NOT_OK === <tt> E_OK := 0x00 E_NOT_OK := 0x01 </tt> === STD_HIGH, STD_LOW === <tt> STD_HIGH := 0x00 STD_LOW := 0x01 </tt> === STD_ACTIVE, STD_IDLE === <tt> STD_ACTIVE := 0x00 STD_IDLE := 0x01 </tt> === STD_ON, STD_OFF === <tt> STD_ON := 0x00 STD_OFF := 0x01 </tt> 5c55eb4c6cac2f9641532ed8e37100351e800908 0 436 562 2014-07-24T10:19:40Z 192.168.2.119 0 Redirected page to [[Standard Types]] wikitext text/x-wiki #REDIRECT [[Standard Types]] c735b79677f435dc952b24ac0f790fb32fe68188 0 437 563 2014-07-24T10:20:01Z 192.168.2.119 0 Redirected page to [[Standard Types]] wikitext text/x-wiki #REDIRECT [[Standard Types]] c735b79677f435dc952b24ac0f790fb32fe68188 0 438 564 2014-07-24T10:20:17Z 192.168.2.119 0 Redirected page to [[Standard Types]] wikitext text/x-wiki #REDIRECT [[Standard Types]] c735b79677f435dc952b24ac0f790fb32fe68188 0 439 565 2014-07-24T10:20:45Z 192.168.2.119 0 Redirected page to [[Standard Types]] wikitext text/x-wiki #REDIRECT [[Standard Types]] c735b79677f435dc952b24ac0f790fb32fe68188 0 440 566 2014-07-24T10:21:11Z 192.168.2.119 0 Redirected page to [[Standard Types]] wikitext text/x-wiki #REDIRECT [[Standard Types]] c735b79677f435dc952b24ac0f790fb32fe68188 0 441 567 2014-07-24T10:21:32Z 192.168.2.119 0 Redirected page to [[Standard Types]] wikitext text/x-wiki #REDIRECT [[Standard Types]] c735b79677f435dc952b24ac0f790fb32fe68188 0 442 568 2014-07-24T10:21:47Z 192.168.2.119 0 Redirected page to [[Standard Types]] wikitext text/x-wiki #REDIRECT [[Standard Types]] c735b79677f435dc952b24ac0f790fb32fe68188 0 443 569 2014-07-24T10:21:58Z 192.168.2.119 0 Redirected page to [[Standard Types]] wikitext text/x-wiki #REDIRECT [[Standard Types]] c735b79677f435dc952b24ac0f790fb32fe68188 0 444 570 2014-07-24T10:22:12Z 192.168.2.119 0 Redirected page to [[Standard Types]] wikitext text/x-wiki #REDIRECT [[Standard Types]] c735b79677f435dc952b24ac0f790fb32fe68188 0 445 571 2014-07-24T10:22:25Z 192.168.2.119 0 Redirected page to [[Standard Types]] wikitext text/x-wiki #REDIRECT [[Standard Types]] c735b79677f435dc952b24ac0f790fb32fe68188 0 446 573 2014-07-24T13:36:53Z 192.168.2.119 0 Created page with "Association for Standardization of Automation- and Measuring Systems Measurement, Calibration and Diagnostics" wikitext text/x-wiki Association for Standardization of Automation- and Measuring Systems Measurement, Calibration and Diagnostics 50c48936459b37bdc6ae51f2d82b84da479676bf 0 59 574 298 2014-07-24T13:38:58Z 192.168.2.119 0 wikitext text/x-wiki Microcontroller Abstraction Layer (MCAL) Software layer containing [[driver]]s to enable the access of on-chip peripheral devices of a microcontroller and off-chip memory mapped peripheral devices by a defined [[API]]. Task: make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer is the lowest software layer of the [[Basic Software]]. The Microcontroller Abstraction Layer consists of the following parts: * I/O Drivers * Communication Drivers * Memory Drivers * Microcontroller Drivers Properties: * Implementation: [[uC]] dependent * Upper Interface (API): standardize-able and uC independent 362cbfdc17a728aa38eb8277b753be1b60479c8c 598 574 2014-07-24T22:17:15Z 192.168.2.119 0 wikitext text/x-wiki Microcontroller Abstraction Layer (MCAL) Software layer containing [[driver]]s to enable the access of on-chip peripheral devices of a microcontroller and off-chip memory mapped peripheral devices by a defined [[API]]. Task: make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer is the lowest software layer of the [[Basic Software]]. The Microcontroller Abstraction Layer consists of the following parts: * [[I/O Drivers]] * [[Communication Drivers]] * [[Memory Drivers]] * [[Microcontroller Drivers]] Properties: * Implementation: [[uC]] dependent * Upper Interface (API): standardize-able and uC independent e6168952596fc9667733b8930462b7e1e7d9c621 0 447 575 2014-07-24T20:46:24Z 192.168.2.119 0 Created page with "'REDIRECT [[Fault, Detection, Isolation and Recovery]]" wikitext text/x-wiki 'REDIRECT [[Fault, Detection, Isolation and Recovery]] 408c02a8818e6fc505420f24b0bc4ca47424f49b 576 575 2014-07-24T20:46:35Z 192.168.2.119 0 Redirected page to [[Fault, Detection, Isolation and Recovery]] wikitext text/x-wiki #REDIRECT [[Fault, Detection, Isolation and Recovery]] 66d2e455fd4b473d9966650367f7f1d61ffdf011 0 12 577 14 2014-07-24T20:49:46Z 192.168.2.119 0 Redirected page to [[Diagnostic Event Manager]] wikitext text/x-wiki #REDIRECT [[Diagnostic Event Manager]] 728981ed3a8598e339050023e2a104573111945d 0 448 578 2014-07-24T20:49:52Z 192.168.2.119 0 Created page with "Diagnostic Event Manager module to which production relevant errors are reported." wikitext text/x-wiki Diagnostic Event Manager module to which production relevant errors are reported. 407cfee907e51468bde06fe1ca3d497798c4e6d0 579 578 2014-07-24T20:50:39Z 192.168.2.119 0 wikitext text/x-wiki Diagnostic Event Manager module to which production relevant errors are reported either from Application Layer (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). 3675b8f6232add0b273eacbd057f40d8af2f0860 584 579 2014-07-24T21:02:55Z 192.168.2.119 0 wikitext text/x-wiki Diagnostic [[Event]] Manager module to which production relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) == [[Port Interface]]s == === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 861daf5819508f552a6f228a692a07e8a29ab484 586 584 2014-07-24T21:05:41Z 192.168.2.119 0 /* Standardized Interface */ wikitext text/x-wiki Diagnostic [[Event]] Manager module to which production relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) == [[Port Interface]]s == === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === Dem_ReportErrorStatus 7b3a3db0dc788b0cca3499ee34a6b445046d0d6f 587 586 2014-07-24T21:06:19Z 192.168.2.119 0 /* Standardized AUTOSAR Interface */ wikitext text/x-wiki Diagnostic [[Event]] Manager module to which production relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) == [[Port Interface]]s == === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus === [[Standardized Interface]] === Dem_ReportErrorStatus d18b8bc047a9c8f7acda8b42fbd9a48cc0a6fa15 588 587 2014-07-24T21:10:09Z 192.168.2.119 0 /* Standardized AUTOSAR Interface */ wikitext text/x-wiki Diagnostic [[Event]] Manager module to which production relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) == [[Port Interface]]s == === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus 140223a88d2d3c32518f8907ee418a572e1280c3 591 588 2014-07-24T21:13:39Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Event Manager (DEM) is a [[Basic Software Module]] of the [[Diagnostic Service Layer]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) == [[Port Interface]]s == === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus 99de8de71113afb748c8450063db29fa34415509 0 330 580 385 2014-07-24T20:57:31Z 192.168.2.119 0 wikitext text/x-wiki A software interface is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[BSWM|Basic Software]] interact which each other through Standardized Interfaces. 13c42f78c2d7c4e8a99e6708399158f1d2e0f5cb 581 580 2014-07-24T20:58:35Z 192.168.2.119 0 wikitext text/x-wiki A software [[interface]] is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[BSWM|Basic Software]] interact which each other through Standardized Interfaces. 65bfa1e5871858a1a6ceb3fe91389aeb66d32677 0 27 582 131 2014-07-24T21:01:10Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 449 583 2014-07-24T21:01:59Z 192.168.2.119 0 Created page with "Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. Standar..." wikitext text/x-wiki Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. == List of Basic Software Modules == TODO 81c6eef662e8e54e9e311ef80e5e4e2f3d8b269e 603 583 2014-07-24T22:23:55Z 192.168.2.119 0 wikitext text/x-wiki Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. == List of Basic Software Modules == === Communication Drivers === * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) === Communication HW Abstraction === * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) === Communication Services === * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) 7d33cba28a6b0ae9e2079184bf8092de707e5a62 604 603 2014-07-24T22:27:44Z 192.168.2.119 0 wikitext text/x-wiki Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. == List of Basic Software Modules == === Communication Drivers === * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) === Communication HW Abstraction === * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) === Communication Services === * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) === I/O Drivers === * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) === I/O HW Abstraction === * [[IO HW Abstraction]] === Memory Drivers === * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) === Memory HW Abstraction === * [[EEPROM Abstraction]] (Ea) === Memory Services === * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) 982da6ce82799f13fbc3717a839d9394c86c92d6 605 604 2014-07-24T22:31:00Z 192.168.2.119 0 wikitext text/x-wiki Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. == List of Basic Software Modules == === Communication Drivers === * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) === Communication HW Abstraction === * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) === Communication Services === * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) === I/O Drivers === * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) === I/O HW Abstraction === * [[IO HW Abstraction]] === Memory Drivers === * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) === Memory HW Abstraction === * [[EEPROM Abstraction]] (Ea) === Memory Services === * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) === Microcontroller Drivers === * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) === Onboard Device Abstraction === * [[Watchdog Interface]] (WdgIf) === RTE === * [[RTE]] (Rte) === System Services === * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[Diagnostic Log and Trace]] (DLT) * [[ECU State Manager]] (EcuM) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) a9914f5464372ef84414ad82ac40a36d9bf309ec 606 605 2014-07-24T22:31:33Z 192.168.2.119 0 wikitext text/x-wiki Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. == List of Basic Software Modules == === Communication Drivers === * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) === Communication HW Abstraction === * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) === Communication Services === * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) === I/O Drivers === * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) === I/O HW Abstraction === * [[IO HW Abstraction]] === Memory Drivers === * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) === Memory HW Abstraction === * [[EEPROM Abstraction]] (Ea) === Memory Services === * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) === Microcontroller Drivers === * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) === Onboard Device Abstraction === * [[Watchdog Interface]] (WdgIf) === RTE === * [[RTE]] (Rte) === System Services === * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[Diagnostic Log and Trace]] (DLT) * [[ECU State Manager]] (EcuM) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) * [[OS]] eec8d727d0e474552b993515f7dfaf8eae60899a 607 606 2014-07-24T22:34:40Z 192.168.2.119 0 wikitext text/x-wiki Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. == List of Basic Software Modules == === Communication Drivers === * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) === Communication HW Abstraction === * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) === Communication Services === * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) === I/O Drivers === * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) === I/O HW Abstraction === * [[IO HW Abstraction]] === Memory Drivers === * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) === Memory HW Abstraction === * [[EEPROM Abstraction]] (Ea) === Memory Services === * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) === Microcontroller Drivers === * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) === Onboard Device Abstraction === * [[Watchdog Interface]] (WdgIf) === RTE === * [[RTE]] (Rte) === System Services === * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] === System Services (as part of System Services) === * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) b1c27aa4aa8dda79eba68714b8fcf89c803f1760 0 450 585 2014-07-24T21:04:04Z 192.168.2.119 0 Created page with "The Application Layer is the layer above the [[RTE]] where all [[Software Component]]s are 'located'." wikitext text/x-wiki The Application Layer is the layer above the [[RTE]] where all [[Software Component]]s are 'located'. 7ed46cb3f5941ad36fa1ff35baecbac4a67d05cd 0 451 589 2014-07-24T21:10:41Z 192.168.2.119 0 Redirected page to [[Function Inhibition Manager]] wikitext text/x-wiki #REDIRECT [[Function Inhibition Manager]] 3c352fbc1594758a2d2eedf84a2d0de4586d9fdb 0 452 590 2014-07-24T21:12:48Z 192.168.2.119 0 Created page with "The Function Inhibition Manager (FIM) is a [[Basic Software Module]] of the [[Diagnostic Service Layer]]." wikitext text/x-wiki The Function Inhibition Manager (FIM) is a [[Basic Software Module]] of the [[Diagnostic Service Layer]]. 70c52bae37058ed74f5337c0d0e8d3b034ba3832 592 590 2014-07-24T21:15:13Z 192.168.2.119 0 wikitext text/x-wiki The Function Inhibition Manager (FIM) is a [[Basic Software Module]] of the [[Diagnostic Service Layer]]. == [[Port Interface]]s == === [[Standardized AUTOSAR Interface]] === Fim_GetFunctionPermission === [[Standardized Interface]] === Fim_DemTriggerOnEventStatus fa32ce040d628c27c8545d9ef5b0f70126cda263 0 453 593 2014-07-24T21:35:54Z 192.168.2.119 0 Created page with "The process of handling faults during system operation is often referred to as FDIR, which stands for Fault Detection, Isolation, and Recovery. == Detection == The crucial fi..." wikitext text/x-wiki The process of handling faults during system operation is often referred to as FDIR, which stands for Fault Detection, Isolation, and Recovery. == Detection == The crucial first step in handling a fault is of course to become aware that it has occurred. Without this detection, no further activities can be performed. When it comes to detection, the original fault is often very hard to detect. What can be detected are the effects of the fault, that is, errors. These are detected by monitoring the state of the system. Errors can manifest in different ways. The main manifestations are # erroneous values in the system (data errors), # erroneous execution time (timing errors), # erroneous sequence or execution order (program flow errors). # erroneous access to system resources, such as memory Errors may propagate and generate consecutive faults which in turn may result in new errors, e.g., an erroneous data value is used as a pointer and causes a memory access violation, which may create an erroneous value in another data value if a value is written to the erroneous memory location. Most mechanisms used for detection of errors allows the system to perform some action to find out more regarding the source of the error (isolation) and to issue corrective or compensating actions (recovery). Ideally, detection is done before the error has propagated any further, thus making it possible to stop further propagation. However, in most cases additional recovery actions are needed == Isolation == Once a fault (or error) has been successfully detected, damage assessment and damage control needs to be performed, i.e. there is a need for isolation. During isolation, efforts are made to find the root cause for the erroneous state in the system, and information (e.g. regarding the spread and cause of the error) is gathered for subsequent use during error recovery. It may not always be possible (or practical) to find the root cause of the erroneous state. Note that isolation in this document refers to isolating the source of the errors, such that recovery is possible. It does not refer to isolation of specific components of a system with the purpose of stopping errors from propagating. In a sense, the word identification may have been a better choice, but as the commonly used word in descriptions of the FDIR process is isolation we will use it here. == Recovery == When the isolation is complete, recovery actions will be initiated. These actions aim at transferring the system into a controlled state, which can be a completely recovered state where nominal service is provided, or a safe degraded state where a limited or no service is provided. The better the isolation results are, the better the recovery actions can perform. If recovery is not successful, a failure may occur, i.e., the system is in an uncontrolled state and its service is not defined. 9dfa53e6bf4ecb55499668e694afe6868d763674 0 164 594 200 2014-07-24T21:39:48Z 192.168.2.119 0 wikitext text/x-wiki Discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition. An error can arise as a result of unforeseen operating conditions or due to a [[fault]] within the system, [[subsystem]] or [[component]] being considered. A fault can manifest itself as an error within the considered [[element]] and, at the end of its latency, the error can cause a [[failure]]. As errors are faults that have been activated and propagated, a single error can (theoretically) have many possible root causes, i.e., faults. fault => error => failure. 202bd91f273a92867d69fd625a06e2dc0d0ced81 0 454 595 2014-07-24T21:53:36Z 192.168.2.119 0 Created page with "Return from [[Interrupt]]" wikitext text/x-wiki Return from [[Interrupt]] cdb81e17cf35c6bcd67ed5bb5d68e720b0962cf4 0 455 596 2014-07-24T21:53:54Z 192.168.2.119 0 Created page with "Generic Configuration Editor" wikitext text/x-wiki Generic Configuration Editor 2a443ea666259a65f5ce3e985035bb6b1b79d0f8 0 52 597 285 2014-07-24T21:54:50Z 192.168.2.119 0 wikitext text/x-wiki Interrupt Service Routine is a [[software routine]] called in case of an [[interrupt]]. == Cat1 == Cat1 interrupts are not supported by the [[OS]] and are only allowed to make a very small selection of OS calls to enable and disable all interrupts. == Cat2 == Cat2 ISRs are supported by the OS and can make OS calls. fb8bd942b515dbf242d0d248f62e8126dc89d421 0 456 599 2014-07-24T22:17:42Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 457 600 2014-07-24T22:17:52Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 458 601 2014-07-24T22:17:59Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 459 602 2014-07-24T22:18:06Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 318 608 372 2014-07-24T22:37:03Z 192.168.2.119 0 wikitext text/x-wiki The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Hardware Abstraction Layer]], the Services Layer offers Operating system services Vehicle network communication and management services Memory services (NVRAM management) Diagnosis Services (including KWP2000 interface and error memory) [[ECU]] state management Task: Provide basic services for application and [[basic software module]]s The Services Layer consists of the following parts: * [[Communication Services]] * [[Memory Services]] * [[System Services]] 5995a00b556e78809e24ca321560a02de057c933 0 460 609 2014-07-24T22:37:26Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 461 610 2014-07-24T22:38:22Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 462 611 2014-07-24T22:38:53Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 463 612 2014-07-24T22:39:18Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 464 613 2014-07-24T22:39:43Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 465 614 2014-07-24T22:40:15Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 466 615 2014-07-24T22:40:47Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 318 616 608 2014-07-24T22:41:23Z 192.168.2.119 0 wikitext text/x-wiki The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Hardware Abstraction Layer]], the Services Layer offers Operating system services Vehicle network communication and management services Memory services (NVRAM management) Diagnosis Services (including KWP2000 interface and error memory) [[ECU]] state management Task: Provide basic services for application and [[Basic Software Module]]s The Services Layer consists of the following parts: * [[Communication Services]] * [[Memory Services]] * [[System Services]] 720eaa40f58aeedb9f6742a359ffea5c9c9d4e57 0 449 617 607 2014-07-24T22:41:51Z 192.168.2.119 0 /* System Services (as part of System Services) */ wikitext text/x-wiki Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. == List of Basic Software Modules == === Communication Drivers === * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) === Communication HW Abstraction === * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) === Communication Services === * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) === I/O Drivers === * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) === I/O HW Abstraction === * [[IO HW Abstraction]] === Memory Drivers === * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) === Memory HW Abstraction === * [[EEPROM Abstraction]] (Ea) === Memory Services === * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) === Microcontroller Drivers === * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) === Onboard Device Abstraction === * [[Watchdog Interface]] (WdgIf) === RTE === * [[RTE]] (Rte) === System Services === * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] === Diagnostic Services (as part of System Services) === * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) d6d3d5cdd85b4120ec704fa2fe13376bb72c6e19 638 617 2014-07-24T22:50:38Z 192.168.2.119 0 /* Communication Services */ wikitext text/x-wiki Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. == List of Basic Software Modules == === Communication Drivers === * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) === Communication HW Abstraction === * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) === Communication Services === * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) === I/O Drivers === * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) === I/O HW Abstraction === * [[IO HW Abstraction]] === Memory Drivers === * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) === Memory HW Abstraction === * [[EEPROM Abstraction]] (Ea) === Memory Services === * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) === Microcontroller Drivers === * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) === Onboard Device Abstraction === * [[Watchdog Interface]] (WdgIf) === RTE === * [[RTE]] (Rte) === System Services === * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] === Diagnostic Services (as part of System Services) === * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) 130e79a8ad9663a98f51056089a078cb701306f2 0 467 618 2014-07-24T22:42:06Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 133 619 164 2014-07-24T22:42:34Z 192.168.2.119 0 wikitext text/x-wiki A specific form of communication in a possibly distributed system in which software entities act as [[client]]s, [[server]]s or both, where 1...n clients are requesting [[service]]s via a specific protocol from typically one server. Client-server communication can be realized by [[synchronous communication]] or [[asynchronous communication]]. -Client takes initiative: requesting that the server performs a service, e.g. client triggers action within server (server does not start action on its own) -Client is after service request blocked / non-blocked -Client expects response from server: [[data flow]] (+ [[control flow]], if blocked) One example for 1 client to n server communication (currently not supported) is a functional request by diagnosis. This has to be treated as a specific exception. 40c2bf6baf5b86bf02bce71158ab62b7e7a8f093 0 468 620 2014-07-24T22:43:34Z 192.168.2.119 0 Redirected page to [[Ethernet Driver]] wikitext text/x-wiki #REDIRECT [[Ethernet Driver]] 7d2be0e1c87fa899f64823292447cc4a248ea9eb 0 124 621 215 2014-07-24T22:43:55Z 192.168.2.119 0 Redirected page to [[FlexRay Driver]] wikitext text/x-wiki #REDIRECT [[FlexRay Driver]] 131b76da53940bf4dd3b0eba063c8456b49c176d 0 376 622 440 2014-07-24T22:44:27Z 192.168.2.119 0 wikitext text/x-wiki Time Triggered [[CAN]] see also [[TTCAN Driver]] 465b79aab85239e4fa69574cc6003fc44b8f71be 0 469 623 2014-07-24T22:44:56Z 192.168.2.119 0 Redirected page to [[CAN Interface]] wikitext text/x-wiki #REDIRECT [[CAN Interface]] 176117ce3792c28a63ea3d5926d8ebc1fcef1b08 0 470 624 2014-07-24T22:45:13Z 192.168.2.119 0 Redirected page to [[CAN Tranceiver Driver]] wikitext text/x-wiki #REDIRECT [[CAN Tranceiver Driver]] 85c330c38ceb0dcd3181cd25bc8e9051b18affcc 0 471 625 2014-07-24T22:45:37Z 192.168.2.119 0 Redirected page to [[Ethernet Interface]] wikitext text/x-wiki #REDIRECT [[Ethernet Interface]] 58e1b3c9ed77cd16047938144c8f4b2e21c7f346 0 472 626 2014-07-24T22:45:58Z 192.168.2.119 0 Redirected page to [[Ethernet Transceiver Driver]] wikitext text/x-wiki #REDIRECT [[Ethernet Transceiver Driver]] bb8bbb5fc1fc92326ae076ca31b1f78c00f52ad3 0 473 627 2014-07-24T22:46:19Z 192.168.2.119 0 Redirected page to [[FlexRay Interface]] wikitext text/x-wiki #REDIRECT [[FlexRay Interface]] 0313b45ad68235f801e4efeda91876f07022d88d 0 474 628 2014-07-24T22:46:38Z 192.168.2.119 0 Redirected page to [[FlexRay Tranceiver Driver]] wikitext text/x-wiki #REDIRECT [[FlexRay Tranceiver Driver]] a2d3c6ec039e0a95ace9f08a3081ba5156cd7baf 0 475 629 2014-07-24T22:46:56Z 192.168.2.119 0 Redirected page to [[LIN Interface]] wikitext text/x-wiki #REDIRECT [[LIN Interface]] 8aa358f8e495921b763da5b3fbe033191269186d 0 476 630 2014-07-24T22:47:18Z 192.168.2.119 0 Redirected page to [[LIN Transceiver Driver]] wikitext text/x-wiki #REDIRECT [[LIN Transceiver Driver]] f8f4a7f8bdb8d3dfd67dd74999d01172334cd8f7 0 477 631 2014-07-24T22:47:40Z 192.168.2.119 0 Redirected page to [[TTCAN Interface]] wikitext text/x-wiki #REDIRECT [[TTCAN Interface]] fddd4451f11b42c51c132b66ea31e17834f190ef 0 478 632 2014-07-24T22:48:45Z 192.168.2.119 0 Redirected page to [[CAN Network Management]] wikitext text/x-wiki #REDIRECT [[CAN Network Management]] 27750763345a2fe7196cb3b3828691a3bcf5de9f 0 479 633 2014-07-24T22:49:06Z 192.168.2.119 0 Redirected page to [[CAN State Manager]] wikitext text/x-wiki #REDIRECT [[CAN State Manager]] 7fc90ba3e1cd3b6d37d6418cd17d9d5486e4bfb3 0 480 634 2014-07-24T22:49:22Z 192.168.2.119 0 Redirected page to [[CAN Transport Layer]] wikitext text/x-wiki #REDIRECT [[CAN Transport Layer]] 89909d4ea30a1831165295a80ea57da817bf742d 0 481 635 2014-07-24T22:49:44Z 192.168.2.119 0 Redirected page to [[Ethernet State Manager]] wikitext text/x-wiki #REDIRECT [[Ethernet State Manager]] 4d25a3c0171756ae2092f711e24b9f8a22645221 0 482 636 2014-07-24T22:50:06Z 192.168.2.119 0 Redirected page to [[FlexRay AUTOSAR Transport Layer]] wikitext text/x-wiki #REDIRECT [[FlexRay AUTOSAR Transport Layer]] a6b0320885b991f25d2684addcfdc201ef213afd 0 483 637 2014-07-24T22:50:26Z 192.168.2.119 0 Redirected page to [[FlexRay ISO Transport Layer]] wikitext text/x-wiki #REDIRECT [[FlexRay ISO Transport Layer]] 827688a14c23c515a4d4fcaf06bba4c5548d4747 0 484 639 2014-07-24T22:50:56Z 192.168.2.119 0 Redirected page to [[FlexRay Network Management]] wikitext text/x-wiki #REDIRECT [[FlexRay Network Management]] ff5fc49bab26ff35d93a51b40cfa321095e20405 0 485 640 2014-07-24T22:51:17Z 192.168.2.119 0 Redirected page to [[FlexRay State Manager]] wikitext text/x-wiki #REDIRECT [[FlexRay State Manager]] 1520d12cdb75aa5db3e2956c40023de72e75b22e 0 486 641 2014-07-24T22:51:41Z 192.168.2.119 0 Redirected page to [[IPDU Multiplexer]] wikitext text/x-wiki #REDIRECT [[IPDU Multiplexer]] 80d8f47e1af12f384bba21e34efa75b68009c8d7 0 487 642 2014-07-24T22:52:05Z 192.168.2.119 0 Redirected page to [[LIN Network Management]] wikitext text/x-wiki #REDIRECT [[LIN Network Management]] b83c4fd66fd18015213cda9cddaf8b97fa6dc8c6 0 488 643 2014-07-24T22:52:23Z 192.168.2.119 0 Redirected page to [[LIN State Manager]] wikitext text/x-wiki #REDIRECT [[LIN State Manager]] dd7947016f0c30a634ac4d71be3aa2c18e9aabc3 0 489 644 2014-07-24T22:52:58Z 192.168.2.119 0 Redirected page to [[Network Management Interface]] wikitext text/x-wiki #REDIRECT [[Network Management Interface]] e79116edc6b13408b232c40c4e3f7cdeea913edf 0 490 645 2014-07-24T22:53:17Z 192.168.2.119 0 Redirected page to [[PDU Router]] wikitext text/x-wiki #REDIRECT [[PDU Router]] c224abc2277f00095bdc9fec06eb52c913d53d2b 0 491 646 2014-07-24T22:53:38Z 192.168.2.119 0 Redirected page to [[SAE J1939 Transport Layer]] wikitext text/x-wiki #REDIRECT [[SAE J1939 Transport Layer]] 35bfc58bccd38bb9e23eccdf4cf7970a4f83a21c 0 492 647 2014-07-24T22:54:01Z 192.168.2.119 0 Redirected page to [[Socket Adaptor]] wikitext text/x-wiki #REDIRECT [[Socket Adaptor]] 6a24b8f83d93e36cbcdce82f64612e2aae3782d7 0 92 648 95 2014-07-24T22:54:36Z 192.168.2.119 0 Redirected page to [[UDP Network Management]] wikitext text/x-wiki #REDIRECT [[UDP Network Management]] 38d79416cd50a0b4d4d36622b4d4ad92f00641a3 0 493 649 2014-07-24T22:54:59Z 192.168.2.119 0 Redirected page to [[Diagnostic Communication Manager]] wikitext text/x-wiki #REDIRECT [[Diagnostic Communication Manager]] a9bfd9adc4675be15b39dbb833d1495f5ff6d457 0 19 650 21 2014-07-24T22:55:26Z 192.168.2.119 0 wikitext text/x-wiki Analog Digital Converter see also [[ADC Driver]] 04ccf3a7cfdf406ca112ad23a8de134015b968d6 0 37 651 40 2014-07-24T22:55:44Z 192.168.2.119 0 wikitext text/x-wiki Digital Input/Output see also [[DIO Driver]] b2111ee110a96fac6138864d3730f922e5be9b4f 0 367 652 431 2014-07-24T22:56:14Z 192.168.2.119 0 wikitext text/x-wiki Input Capture Unit see also [[ICU Driver]] cab02a536245bb54bdec664c29c6310c42c04021 0 79 653 82 2014-07-24T22:56:36Z 192.168.2.119 0 wikitext text/x-wiki Pulse Width Modulation see also [[PWM Driver]] 1404fb266f797ac9c4005ca462defc6353ac65f8 0 494 654 2014-07-24T22:57:10Z 192.168.2.119 0 Redirected page to [[EEPROM Driver]] wikitext text/x-wiki #REDIRECT [[EEPROM Driver]] 4d54767f7de3c1eb14b78dd392b257b166b61700 0 495 655 2014-07-24T22:57:27Z 192.168.2.119 0 Redirected page to [[Flash Driver]] wikitext text/x-wiki #REDIRECT [[Flash Driver]] a5fc4da3a5fb23c696d8d7030a6dc6fa7ddfb900 0 496 656 2014-07-24T22:57:46Z 192.168.2.119 0 Redirected page to [[RAM Test]] wikitext text/x-wiki #REDIRECT [[RAM Test]] 87ac0f4c030c37a9af002077922bdcb8d43c394b 0 497 657 2014-07-24T22:58:03Z 192.168.2.119 0 Redirected page to [[Flash Test]] wikitext text/x-wiki #REDIRECT [[Flash Test]] 47b25b565b48bbd47d8e2ca5265a45f7f815ed75 0 15 658 17 2014-07-24T22:58:23Z 192.168.2.119 0 Redirected page to [[EEPROM Abstraction]] wikitext text/x-wiki #REDIRECT [[EEPROM Abstraction]] 654b1e745bf30af7069aa0e1e94065f2b69d0c20 0 14 659 16 2014-07-24T22:58:47Z 192.168.2.119 0 Redirected page to [[Flash EEPROM Emulation]] wikitext text/x-wiki #REDIRECT [[Flash EEPROM Emulation]] 1e3e2ffc7ebd6e545c31c819551645ed58849e8a 0 498 660 2014-07-24T22:59:08Z 192.168.2.119 0 Redirected page to [[Memory Abstraction Interface]] wikitext text/x-wiki #REDIRECT [[Memory Abstraction Interface]] 624b9d6a5dc51992faee423ac463a8e6b66e6a79 0 18 661 449 2014-07-24T22:59:34Z 192.168.2.119 0 wikitext text/x-wiki Non-volatile memory see also [[NVRAM Manager]] fdd13c3cd41144401fa2d4604f8638f25c5787c0 0 499 662 2014-07-24T22:59:54Z 192.168.2.119 0 Redirected page to [[Core Test]] wikitext text/x-wiki #REDIRECT [[Core Test]] 2108e31934d01b960287546dbf8b082aa47d085a 0 366 663 430 2014-07-24T23:00:22Z 192.168.2.119 0 wikitext text/x-wiki General Purpose Timer see also [[GPT Driver]] 8f89c1ee1d39e5a74c6b5c028c6f9eddadaa9d44 0 371 664 435 2014-07-24T23:00:47Z 192.168.2.119 0 wikitext text/x-wiki Micro Controller Unit see also [[MCU Driver]] bf5f7f1a0c80559f873060a0f56f468f78a71817 665 664 2014-07-24T23:00:56Z 192.168.2.119 0 wikitext text/x-wiki Microcontroller Unit see also [[MCU Driver]] a70adfdbae360383edee0cade0c202f625eb04bc 0 500 666 2014-07-24T23:01:31Z 192.168.2.119 0 Redirected page to [[Watchdog Driver]] wikitext text/x-wiki #REDIRECT [[Watchdog Driver]] 169a8c328210e77d3206aefdcee9eff530b23a6d 0 501 667 2014-07-24T23:01:47Z 192.168.2.119 0 Redirected page to [[Watchdog Interface]] wikitext text/x-wiki #REDIRECT [[Watchdog Interface]] f3a6cf059a94b525a20121ce87e85e9c82fc4923 0 502 668 2014-07-24T23:02:08Z 192.168.2.119 0 Redirected page to [[COM Manager]] wikitext text/x-wiki #REDIRECT [[COM Manager]] 750a6f075ba87fada73636b3e7c9fb9a2a19592e 0 449 669 638 2014-07-24T23:03:18Z 192.168.2.119 0 wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. == List of Basic Software Modules == === Communication Drivers === * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) === Communication HW Abstraction === * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) === Communication Services === * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) === I/O Drivers === * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) === I/O HW Abstraction === * [[IO HW Abstraction]] === Memory Drivers === * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) === Memory HW Abstraction === * [[EEPROM Abstraction]] (Ea) === Memory Services === * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) === Microcontroller Drivers === * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) === Onboard Device Abstraction === * [[Watchdog Interface]] (WdgIf) === RTE === * [[RTE]] (Rte) === System Services === * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] === Diagnostic Services (as part of System Services) === * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) eed1ac2deb1b94c9f19ce6df9bee5ce799c58ea7 671 669 2014-07-24T23:03:58Z 192.168.2.119 0 /* System Services */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] Basic Software ([[BSW]]) Modules are a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. == List of Basic Software Modules == === Communication Drivers === * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) === Communication HW Abstraction === * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) === Communication Services === * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) === I/O Drivers === * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) === I/O HW Abstraction === * [[IO HW Abstraction]] === Memory Drivers === * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) === Memory HW Abstraction === * [[EEPROM Abstraction]] (Ea) === Memory Services === * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) === Microcontroller Drivers === * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) === Onboard Device Abstraction === * [[Watchdog Interface]] (WdgIf) === RTE === * [[RTE]] (Rte) === System Services === * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] === Diagnostic Services (as part of System Services) === * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) 3341325d1a076bc91d867558ec939c1a97d14741 0 503 670 2014-07-24T23:03:39Z 192.168.2.119 0 Redirected page to [[Crypto Service Manager]] wikitext text/x-wiki #REDIRECT [[Crypto Service Manager]] 8f76b3b23ea1d74e3e917a8c928dd2aaebef88cc 0 504 672 2014-07-24T23:04:07Z 192.168.2.119 0 Redirected page to [[ECU State Manager]] wikitext text/x-wiki #REDIRECT [[ECU State Manager]] a25522994b0eb36a23d4b367d6d3da0bf180fa3f 0 505 673 2014-07-24T23:04:31Z 192.168.2.119 0 Redirected page to [[Synchronized Time-Base Manager]] wikitext text/x-wiki #REDIRECT [[Synchronized Time-Base Manager]] 2e03520d26962f0043f9cfaacc1a352f607e9dd5 0 506 674 2014-07-24T23:04:46Z 192.168.2.119 0 Redirected page to [[Watchdog Manager]] wikitext text/x-wiki #REDIRECT [[Watchdog Manager]] 4a27cfb7274f7af7d967db76b29024fcd0227325 0 507 675 2014-07-24T23:05:02Z 192.168.2.119 0 Redirected page to [[Diagnostic Log and Trace]] wikitext text/x-wiki #REDIRECT [[Diagnostic Log and Trace]] a58b7e28a27c741f4194462617fd579dcb7ba093 0 448 676 591 2014-07-24T23:07:23Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Event Manager (DEM) is a [[Basic Software Module]] of the [[Diagnostic Service Layer]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus 50496a9a1de6f4232b03a14c44df6232cf859437 0 452 677 592 2014-07-24T23:07:38Z 192.168.2.119 0 wikitext text/x-wiki The Function Inhibition Manager (FIM) is a [[Basic Software Module]] of the [[Diagnostic Service Layer]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Fim_GetFunctionPermission === [[Standardized Interface]] === Fim_DemTriggerOnEventStatus 9c6d7787e5510d2662c2a0fc9e8406a4bd1fdc07 0 162 678 182 2014-07-24T23:09:23Z 192.168.2.119 0 wikitext text/x-wiki The Development Error Tracer (Det) is a [[Basic Software Module]] of the [[Diagnostic Service Layer]]. Development Error Tracer module to which development errors are reported. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 13019c48ce02ab9938e457be35d178dcdd70f195 0 508 679 2014-07-24T23:10:15Z 192.168.2.119 0 Created page with "The CAN Driver (Can) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Stand..." wikitext text/x-wiki The CAN Driver (Can) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 0d65e1359961b0d7042621f51810f0344be3b75f 0 509 680 2014-07-24T23:10:58Z 192.168.2.119 0 Created page with "The Ethernet Driver (Eth) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === ..." wikitext text/x-wiki The Ethernet Driver (Eth) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 7e509e41aae0945da4abc4f86fa35987253fdac8 0 510 681 2014-07-24T23:11:23Z 192.168.2.119 0 Created page with "The FlexRay Driver (Fr) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === St..." wikitext text/x-wiki The FlexRay Driver (Fr) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === caa59e56099b623e6627aad2c7fffed91a62a676 0 511 682 2014-07-24T23:11:49Z 192.168.2.119 0 Created page with "The LIN Driver (Lin) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Stand..." wikitext text/x-wiki The LIN Driver (Lin) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 59f35b22c0aa8b1d8ea5e5f4c7d6458a4adf8451 0 512 683 2014-07-24T23:12:23Z 192.168.2.119 0 Created page with "The TTCAN Driver (Ttcan) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === S..." wikitext text/x-wiki The TTCAN Driver (Ttcan) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === be9e6467c6d5130fb8a1fae481529161cc43d439 0 513 684 2014-07-24T23:12:47Z 192.168.2.119 0 Created page with "The SPI Handler Driver (Spi) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === ===..." wikitext text/x-wiki The SPI Handler Driver (Spi) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f100f6e592fc1bd8b5db092de13318bb50585cee 0 514 685 2014-07-24T23:17:11Z 192.168.2.119 0 Created page with "The CAN Interface (CanIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === ..." wikitext text/x-wiki The CAN Interface (CanIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f599ac3e861b0babfea9aa89cde9db0268d0d9f2 0 515 686 2014-07-24T23:17:34Z 192.168.2.119 0 Created page with "The CAN Tranceiver Driver (CanTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === Standardized AUTOSAR Interfa..." wikitext text/x-wiki The CAN Tranceiver Driver (CanTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === baf7c921b8d18195b0ebc9b9baa674e628a49721 0 516 687 2014-07-24T23:17:53Z 192.168.2.119 0 Created page with "The Ethernet Interface (EthIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] ..." wikitext text/x-wiki The Ethernet Interface (EthIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 6bfef5f9531c3c2e905b1c72391ecf31943dadd9 0 517 688 2014-07-24T23:18:16Z 192.168.2.119 0 Created page with "The Ethernet Transceiver Driver (EthTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === Standardized AUTOSAR I..." wikitext text/x-wiki The Ethernet Transceiver Driver (EthTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 5d945ef0f97ffc8058db777d7779c9071ee37712 0 518 689 2014-07-24T23:18:34Z 192.168.2.119 0 Created page with "The FlexRay Interface (FrIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] ==..." wikitext text/x-wiki The FlexRay Interface (FrIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === ddde383ef0124a8c259882d923c0b0c101d09069 0 519 690 2014-07-24T23:18:52Z 192.168.2.119 0 Created page with "The FlexRay Tranceiver Driver (FrTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === Standardized AUTOSAR Inte..." wikitext text/x-wiki The FlexRay Tranceiver Driver (FrTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 6bce3fbe7a3ba9a35567d318e6d3cd5f334c5fc1 0 520 691 2014-07-24T23:19:11Z 192.168.2.119 0 Created page with "The LIN Interface (LinIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === ..." wikitext text/x-wiki The LIN Interface (LinIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 49e4e10f3edc5109f92e6bdb4c77c10a76d35f99 0 521 692 2014-07-24T23:19:32Z 192.168.2.119 0 Created page with "The LIN Transceiver Driver (LinTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === Standardized AUTOSAR Interf..." wikitext text/x-wiki The LIN Transceiver Driver (LinTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === ccffeb32ada6b36251e6fb823fae0cf962090ee0 0 522 693 2014-07-24T23:19:52Z 192.168.2.119 0 Created page with "The TTCAN Interface (TtcanIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] =..." wikitext text/x-wiki The TTCAN Interface (TtcanIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 1c941b57b3d7421c8ef39e436ff08ac18a01a713 0 523 694 2014-07-24T23:20:28Z 192.168.2.119 0 Created page with "The CAN Network Management (CanNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] ==..." wikitext text/x-wiki The CAN Network Management (CanNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 39afe1262381bcaca86fd533b4a5d9485dc99c18 0 524 695 2014-07-24T23:20:48Z 192.168.2.119 0 Created page with "The CAN State Manager (CanSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === =..." wikitext text/x-wiki The CAN State Manager (CanSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 2d3bd96d0a858f14a1f24b18555416fc9072f229 0 525 696 2014-07-24T23:21:06Z 192.168.2.119 0 Created page with "The CAN Transport Layer (CanTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === ..." wikitext text/x-wiki The CAN Transport Layer (CanTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f33139cffb233504d84578e262f54666660f7b60 0 526 697 2014-07-24T23:21:30Z 192.168.2.119 0 Created page with "The Ethernet State Manager (EthSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] ==..." wikitext text/x-wiki The Ethernet State Manager (EthSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 13025a4e61020fdcb8a27b6701d2aa34a835b590 0 527 698 2014-07-24T23:22:06Z 192.168.2.119 0 Created page with "The FlexRay AUTOSAR Transport Layer (FrArTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === Standardized AUTOSAR Inte..." wikitext text/x-wiki The FlexRay AUTOSAR Transport Layer (FrArTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 94af9dcf71c135d931b5c40694943fc893bf5493 0 528 699 2014-07-24T23:22:26Z 192.168.2.119 0 Created page with "The FlexRay ISO Transport Layer (FrTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]..." wikitext text/x-wiki The FlexRay ISO Transport Layer (FrTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 94a981f50c2ed821965f7358d20b2a9a7e97453f 0 529 700 2014-07-24T23:22:48Z 192.168.2.119 0 Created page with "The FlexRay Network Management (FrNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]]..." wikitext text/x-wiki The FlexRay Network Management (FrNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === ae708733b4458b337123ed34a6260ee66f1d5322 0 530 701 2014-07-24T23:23:08Z 192.168.2.119 0 Created page with "The FlexRay State Manager (FrSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === ..." wikitext text/x-wiki The FlexRay State Manager (FrSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 2bcb7c27037da6dff5aa9d48b26e99156ecd6144 0 531 702 2014-07-24T23:23:29Z 192.168.2.119 0 Created page with "The IPDU Multiplexer (IpduM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === ==..." wikitext text/x-wiki The IPDU Multiplexer (IpduM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 39adcd51ef2b04445196879baf8dad2a93a0ddda 0 532 703 2014-07-24T23:23:48Z 192.168.2.119 0 Created page with "The LIN Network Management (LinNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] ==..." wikitext text/x-wiki The LIN Network Management (LinNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 4d0d4eee67cb4b020356000240bb1a695cfa3602 0 533 704 2014-07-24T23:24:12Z 192.168.2.119 0 Created page with "The LIN State Manager (LinSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === =..." wikitext text/x-wiki The LIN State Manager (LinSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 0cfe6d9ec548975ed73ad73f329cb670701f3ee2 0 534 705 2014-07-24T23:24:33Z 192.168.2.119 0 Created page with "The Network Management Interface (Nm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]]..." wikitext text/x-wiki The Network Management Interface (Nm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 7476187cb6f4e9e9e618bd28195d66746ab2af09 0 535 706 2014-07-24T23:24:59Z 192.168.2.119 0 Created page with "The PDU Router (PduR) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Sta..." wikitext text/x-wiki The PDU Router (PduR) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 94e9be2b6c831fa885722eefebd9915474c48b19 0 536 707 2014-07-24T23:25:18Z 192.168.2.119 0 Created page with "The SAE J1939 Transport Layer (J1939Tp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === Standardized AUTOSAR Interface..." wikitext text/x-wiki The SAE J1939 Transport Layer (J1939Tp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 489f29246472b5007b113194bfeb14a77cc67c2f 0 537 708 2014-07-24T23:25:35Z 192.168.2.119 0 Created page with "The Socket Adaptor (SoAd) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [..." wikitext text/x-wiki The Socket Adaptor (SoAd) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === c966df2e09b3ad8c4c753b0e1d63530928bf32b4 0 538 709 2014-07-24T23:25:56Z 192.168.2.119 0 Created page with "The UDP Network Management (UdpNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] ==..." wikitext text/x-wiki The UDP Network Management (UdpNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === e9be95cb6e02b33722fefaf9c072f6dea91610c7 0 539 710 2014-07-24T23:26:24Z 192.168.2.119 0 Created page with "The Diagnostic Communication Manager (Dcm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === Standardized AUTOSAR Interf..." wikitext text/x-wiki The Diagnostic Communication Manager (Dcm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 349410fa3fcb1a294a0a76e3e1387c92bc1df726 0 540 711 2014-07-24T23:27:03Z 192.168.2.119 0 Created page with "The ADC Driver (Adc) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standardized In..." wikitext text/x-wiki The ADC Driver (Adc) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === becccecde0f8b33787c78f76a0f91aa9b496937b 0 541 712 2014-07-24T23:27:19Z 192.168.2.119 0 Created page with "The DIO Driver (Dio) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standardized In..." wikitext text/x-wiki The DIO Driver (Dio) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === c17fe404938709378de572aa4abb1fe21ba85c12 0 542 713 2014-07-24T23:27:35Z 192.168.2.119 0 Created page with "The ICU Driver (Icu) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standardized In..." wikitext text/x-wiki The ICU Driver (Icu) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === cb73b06d18ead69016fcbbaf2093970610f3bf2c 0 543 714 2014-07-24T23:27:52Z 192.168.2.119 0 Created page with "The PWM Driver (Pwm) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standardized In..." wikitext text/x-wiki The PWM Driver (Pwm) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === ab3c4d0b2dfaf9695a90ef429dc47a0e289a28ee 0 544 715 2014-07-24T23:28:08Z 192.168.2.119 0 Created page with "The Port Driver (Port) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standardized ..." wikitext text/x-wiki The Port Driver (Port) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 08638b71661de16683588366ac1219b924c358f9 0 545 716 2014-07-24T23:28:54Z 192.168.2.119 0 Created page with "The IO HW Abstraction is a [[Basic Software Module]] of the [[I/O HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standar..." wikitext text/x-wiki The IO HW Abstraction is a [[Basic Software Module]] of the [[I/O HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 70eabdcb43d9fa22bd053a95d728ff652997b291 0 546 717 2014-07-24T23:29:32Z 192.168.2.119 0 Created page with "The EEPROM Driver (Eep) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standardi..." wikitext text/x-wiki The EEPROM Driver (Eep) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 3a8c61794640d4188210b4aa78bb616135ec6041 0 547 718 2014-07-24T23:29:56Z 192.168.2.119 0 Created page with "The Flash Driver (Fls) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standardiz..." wikitext text/x-wiki The Flash Driver (Fls) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 2727a7159c7c1020d22b11f386a03f625f2b3c19 0 548 719 2014-07-24T23:30:13Z 192.168.2.119 0 Created page with "The RAM Test (RamTst) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standardize..." wikitext text/x-wiki The RAM Test (RamTst) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === e43fa52d3b6feb0b690488fbc3b50cd55723ea46 0 549 720 2014-07-24T23:30:31Z 192.168.2.119 0 Created page with "The Flash Test (FlsTst) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standardi..." wikitext text/x-wiki The Flash Test (FlsTst) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 4ea1221bd3882fdced5620658f73a4c6d6181b64 0 550 721 2014-07-24T23:31:01Z 192.168.2.119 0 Created page with "The EEPROM Abstraction (Ea) is a [[Basic Software Module]] of the [[Memory HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === ..." wikitext text/x-wiki The EEPROM Abstraction (Ea) is a [[Basic Software Module]] of the [[Memory HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 197f0943fb41e724fabc09aa6ecad12d8e39a061 0 551 722 2014-07-24T23:31:29Z 192.168.2.119 0 Created page with "The Flash EEPROM Emulation (Fee) is a [[Basic Software Module]] of the [[Memory Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [..." wikitext text/x-wiki The Flash EEPROM Emulation (Fee) is a [[Basic Software Module]] of the [[Memory Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === d3a85729f7c784baa891754728d0e79031760ea7 0 552 723 2014-07-24T23:31:46Z 192.168.2.119 0 Created page with "The Memory Abstraction Interface (MemIf) is a [[Basic Software Module]] of the [[Memory Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] ===..." wikitext text/x-wiki The Memory Abstraction Interface (MemIf) is a [[Basic Software Module]] of the [[Memory Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === d85c39229f0437a5c97b9bdd2f4343c25493255b 0 553 724 2014-07-24T23:32:03Z 192.168.2.119 0 Created page with "The NVRAM Manager (NvM) is a [[Basic Software Module]] of the [[Memory Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standard..." wikitext text/x-wiki The NVRAM Manager (NvM) is a [[Basic Software Module]] of the [[Memory Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 3530ccb960bc247be71123a68fdc5d45eb75e231 0 554 725 2014-07-24T23:32:31Z 192.168.2.119 0 Created page with "The Core Test (CoreTst) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === ..." wikitext text/x-wiki The Core Test (CoreTst) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === d1c60eddbe4cc4864aa8c7d053d4954e76b0b9f2 0 555 726 2014-07-24T23:32:53Z 192.168.2.119 0 Created page with "The GPT Driver (Gpt) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Sta..." wikitext text/x-wiki The GPT Driver (Gpt) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 7b7a948017760442c297b9464276aa55a92abca0 0 556 727 2014-07-24T23:33:11Z 192.168.2.119 0 Created page with "The MCU Driver (Mcu) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Sta..." wikitext text/x-wiki The MCU Driver (Mcu) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === d6c9b4601f6082b53fcf8c79f71f913b7c504d63 0 557 728 2014-07-24T23:33:32Z 192.168.2.119 0 Created page with "The Watchdog Driver (Wdg) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === ..." wikitext text/x-wiki The Watchdog Driver (Wdg) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f8cf83e4fa475427c43f6a32800b539e08cd41ad 0 558 729 2014-07-24T23:33:58Z 192.168.2.119 0 Created page with "The Watchdog Interface (WdgIf) is a [[Basic Software Module]] of the [[Onboard Device Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] ==..." wikitext text/x-wiki The Watchdog Interface (WdgIf) is a [[Basic Software Module]] of the [[Onboard Device Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f967ab6491a8e89de1ab1f2fa12c86b02e45aa4b 0 559 730 2014-07-24T23:34:35Z 192.168.2.119 0 Created page with "The COM Manager (ComM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Standardi..." wikitext text/x-wiki The COM Manager (ComM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === b0e65a856673ca2f217ce279187dd60a94b08dce 0 560 731 2014-07-24T23:34:55Z 192.168.2.119 0 Created page with "The BSW Mode Manager (BswM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Stan..." wikitext text/x-wiki The BSW Mode Manager (BswM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 3206ceeeeb13c99ffe0ae779f6c498c0de6aa0c8 0 561 732 2014-07-24T23:35:14Z 192.168.2.119 0 Created page with "The Crypto Service Manager (Csm) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [..." wikitext text/x-wiki The Crypto Service Manager (Csm) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === e30b70a90f584eeac662bc201f08cb68de3f59a7 0 562 733 2014-07-24T23:35:34Z 192.168.2.119 0 Created page with "The ECU State Manager (EcuM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Sta..." wikitext text/x-wiki The ECU State Manager (EcuM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f256b101f167543cca4a796978319bb5e7b697dc 0 563 734 2014-07-24T23:35:51Z 192.168.2.119 0 Created page with "The Synchronized Time-Base Manager (StbM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] ==..." wikitext text/x-wiki The Synchronized Time-Base Manager (StbM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 660875617d9203b8aff622172e2c0a05ca10997e 0 564 735 2014-07-24T23:36:09Z 192.168.2.119 0 Created page with "The Watchdog Manager (WdgM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === Stan..." wikitext text/x-wiki The Watchdog Manager (WdgM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 93a06933bc0f4ee6af3a2e775a79893e7911cdd0 0 565 736 2014-07-24T23:36:25Z 192.168.2.119 0 Created page with "The Diagnostic Log and Trace (DLT) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === ===..." wikitext text/x-wiki The Diagnostic Log and Trace (DLT) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 1d9bc5e759cdbc22b18d1b3b12eaff964093e23d 756 736 2014-07-25T06:49:32Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Log and Trace (DLT) is a [[Basic Software Module]] of the [[Diagnostic Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f585ff15fa94ce30b3d4eccc1fcd112a0590a435 0 566 737 2014-07-24T23:40:57Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 112 738 558 2014-07-24T23:41:03Z 192.168.2.119 0 wikitext text/x-wiki The AUTOSAR Interface of a software component ([[SW-C]]) refers to the collection of all [[port]]s of that component through which it interacts with other components. An AUTOSAR Interface defines the information exchanged between software components and/or [[BSWM|BSW Modules]]. This description is independent of a specific programming language, [[ECU]] or network technology. AUTOSAR Interfaces are used in defining the ports of software-components and/or BSW modules. Through these ports software-components and/or BSW modules can communicate with each other (send or receive information or invoke services). AUTOSAR makes it possible to implement this communication between SW-C and/or BSW modules either locally or via a [[network]]. ce603739e87193a5ab18f8865b8968d476b4697f 0 26 739 129 2014-07-24T23:43:11Z 192.168.2.119 0 Redirected page to [[Basic Software]] wikitext text/x-wiki #REDIRECT [[Basic Software]] 32c0eccc421e5a34a7390246d73dd39d2b803663 0 567 740 2014-07-24T23:43:18Z 192.168.2.119 0 Created page with "The Basic Software provides the infrastructural (schematic dependent and schematic independent) functionalities of an [[ECU]]. It consists of [[Integration Code]] and Standa..." wikitext text/x-wiki The Basic Software provides the infrastructural (schematic dependent and schematic independent) functionalities of an [[ECU]]. It consists of [[Integration Code]] and [[Standard Software]]. c6ae9e246b96aa389d6938c17fbb562f4c6eabe6 745 740 2014-07-25T05:06:40Z 192.168.2.119 0 wikitext text/x-wiki The Basic Software provides the infrastructural (schematic dependent and schematic independent) functionalities of an [[ECU]]. It consists of [[Integration Code]] and [[Standard Software]]. Basic Software is divided into four different layers: * [[Services Layer]] * [[ECU Abstraction Layer]] * [[Complex Device Driver|Complex Driver]]s * [[Microcontroller Abstraction Layer]] (MCAL) e101e44f29f3542ce732ced27d678269a704984d 0 329 741 474 2014-07-24T23:43:29Z 192.168.2.119 0 wikitext text/x-wiki This is an AUTOSAR Interface which is standardized within the AUTOSAR project. AUTOSAR [[Service]]s interact with other [[Software Component]]s through a Standardized AUTOSAR Interface. A Standardized AUTOSAR Interface is an [[AUTOSAR Interface]] whose syntax and semantics are standardized in AUTOSAR. The Standardized AUTOSAR Interfaces are typically used to define [[AUTOSAR Service]]s, which are standardized [[service]]s provided by the AUTOSAR [[Basic Software]] to the application Software Components. 43f2cfbafbc8298a0b2d015bf3092260b0941f58 0 331 742 386 2014-07-24T23:44:12Z 192.168.2.119 0 wikitext text/x-wiki Standard Software is software which provides schematic independent infrastructural functionalities on an [[ECU]]. It contains only [[Standardized Interface]]s, [[Standardized AUTOSAR Interface]]s and/or [[Private Interface]]s. 796504247492c4bbcb4f2087d04151fe2b21f497 0 330 743 581 2014-07-24T23:45:48Z 192.168.2.119 0 wikitext text/x-wiki A software [[interface]] is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[Basic Software]] interact which each other through Standardized Interfaces. A Standardized Interface is an [[API]] which is standardized within AUTOSAR without using the [[AUTOSAR Interface]] technique. These "Standardized Interfaces" are typically defined for a specific programming language (like "C"). Because of this, "standardized interfaces" are typically used between Software Modules which are always on the same [[ECU]]. When software modules communicate through a "standardized interface", it is NOT possible any more to route the communication between the software-modules through a network. a265b0b2cf06e39268ba890738c1141e1ec94276 0 568 744 2014-07-25T05:03:51Z 192.168.2.119 0 Created page with "AUTOSAR defines four abstraction layers, resp. Software Layers: * [[Application Layer]] * [[Runtime Environment]] (RTE) * [[Basic Software]] (BSW) * Microcontroller (hardware)" wikitext text/x-wiki AUTOSAR defines four abstraction layers, resp. Software Layers: * [[Application Layer]] * [[Runtime Environment]] (RTE) * [[Basic Software]] (BSW) * Microcontroller (hardware) 5f9a6ee20f904301e36f4b86aa67208291df7d5d 0 59 746 598 2014-07-25T05:53:32Z 192.168.2.119 0 Redirected page to [[Microcontroller Abstraction Layer]] wikitext text/x-wiki #REDIRECT [[Microcontroller Abstraction Layer]] 182d15d02f0dd54445908590bebed01133fff039 0 256 747 297 2014-07-25T05:57:29Z 192.168.2.119 0 wikitext text/x-wiki The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: * [[I/O Drivers]] * [[Communication Drivers]] * [[Memory Drivers]] * [[Microcontroller Drivers]] 023c03343e8c77d558c31b7f934755f046860667 751 747 2014-07-25T06:33:42Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Microcontroller Abstraction Layer]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Microcontroller Abstraction Layer]] c3a3f8fa5bc17054dbcd3c8fe9d1cbffdb783f0c 0 58 748 61 2014-07-25T05:58:39Z 192.168.2.119 0 Redirected page to [[Microcontroller]] wikitext text/x-wiki #REDIRECT [[Microcontroller]] 97b66a5dc305c63a0a072fea7e435f4bdd7b7771 0 456 749 599 2014-07-25T06:13:14Z 192.168.2.119 0 Redirected page to [[Basic Software Module#I/O Drivers]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#I/O Drivers]] 5310f030a8bdfb192d86f25677c1649e631a6400 0 449 750 671 2014-07-25T06:32:33Z 192.168.2.119 0 wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The [[Basic Software]] (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. = Service Layer = ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services (as part of System Services) ==== * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = c3d532694515495e352e495aeaf288b4c87dd4f6 758 750 2014-07-25T06:50:13Z 192.168.2.119 0 /* Diagnostic Services (as part of System Services) */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The [[Basic Software]] (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. = Service Layer = ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = 85f9e909d2b9105d37ac21e546807d5e2e3c6f9f 0 569 752 2014-07-25T06:47:24Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Service Layer]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Service Layer]] 87f5e8211f383e9de355f3af63b99be2b3ecce5b 0 460 753 609 2014-07-25T06:48:10Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Communication Services]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Communication Services]] f87409ec2ef61409dbb70171fa0ced2f92834a64 0 464 754 613 2014-07-25T06:48:30Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Memory Services]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Memory Services]] 2cf2b329a579ce005f6c0c0c8148f5cac4da8f2e 0 466 755 615 2014-07-25T06:48:47Z 192.168.2.119 0 Redirected page to [[Basic Software Module#System Services]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#System Services]] dcf281e6cf19e02d905dddd1718e7d0e7f5b3bdf 0 467 757 618 2014-07-25T06:49:46Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Diagnostic Services]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Diagnostic Services]] 1c8926410aa19b9d2230fdf842cb4e8083ea286d 0 162 759 678 2014-07-25T06:50:49Z 192.168.2.119 0 wikitext text/x-wiki The Development Error Tracer (Det) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Development Error Tracer module to which development errors are reported. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 7cc902fd26e4d418914131f302de0df5e0fc48a9 0 448 760 676 2014-07-25T06:51:02Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Event Manager (DEM) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus dcd4fd26f79bb6a7db4f119732f438351c864bc9 0 452 761 677 2014-07-25T06:51:14Z 192.168.2.119 0 wikitext text/x-wiki The Function Inhibition Manager (FIM) is a [[Basic Software Module]] of the [[Diagnostic Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Fim_GetFunctionPermission === [[Standardized Interface]] === Fim_DemTriggerOnEventStatus 93d0afdc48d24badb9fa151d812d4cebdefc6c98 0 461 762 610 2014-07-25T06:51:43Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Communication HW Abstraction]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Communication HW Abstraction]] 23a6f63ea4d48e6a39bd34a1f0a050e139d10187 0 463 763 612 2014-07-25T06:52:03Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Memory HW Abstraction]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Memory HW Abstraction]] 8ff606ec60677f8bcbe7cbe4f84c4bd4c9bbc1bb 0 465 764 614 2014-07-25T06:52:21Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Onboard Device Abstraction]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Onboard Device Abstraction]] b59e3eeb3063b0a212df41f826bfdb02fe4d1e54 0 462 765 611 2014-07-25T06:52:38Z 192.168.2.119 0 Redirected page to [[Basic Software Module#I/O HW Abstraction]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#I/O HW Abstraction]] cb7106253aef66860029e41d66aac7058bdfa74d 0 457 766 600 2014-07-25T06:52:58Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Communication Drivers]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Communication Drivers]] 821a803facb6bdcc010bace9dfc0978c3f05f6bb 0 458 767 601 2014-07-25T06:53:37Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Memory Drivers]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Memory Drivers]] b93a42678fcd9e4dd060db50ee7bd84ed06e49b0 0 459 768 602 2014-07-25T06:53:55Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Microcontroller Drivers]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Microcontroller Drivers]] ceca120c98b11c687502bae9d684a6022464d17c 0 449 769 758 2014-07-25T06:56:45Z 192.168.2.119 0 /* ECU Abstraction Layer */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The [[Basic Software]] (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. = Service Layer = ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = a5c897947324655743799dfc9a0be65782628acc 771 769 2014-07-25T07:01:59Z 192.168.2.119 0 /* Service Layer */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The [[Basic Software]] (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = 9a256d4dd645454ee04de2d8a3a0e592df025faf 773 771 2014-07-25T07:04:38Z 192.168.2.119 0 /* Complex Drivers */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The [[Basic Software]] (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = The Complex Device Driver (CDD) generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with [[Software Component]]s in specific ways and can also interact directly with other Basic Software Modules. 844cf802f309b202e97afca6d9b016346b4be600 781 773 2014-07-25T07:46:47Z 192.168.2.119 0 /* Complex Drivers */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The [[Basic Software]] (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = The Complex Device Driver (CDD) generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with [[Software Component]]s in specific ways and can also interact directly with other Basic Software Modules. The Complex Drivers Layer spans from the hardware to the [[RTE]]. It provides the possibility to integrate special purpose functionality, e.g. drivers for specific devices: * which are not specified within AUTOSAR, * with very high timing constrains or * for migration purposes etc. d331800542768c586dac2aa4cebc0b290f64a3ce 782 781 2014-07-25T07:55:43Z 192.168.2.119 0 /* Services Layer */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The [[Basic Software]] (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = The Complex Device Driver (CDD) generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with [[Software Component]]s in specific ways and can also interact directly with other Basic Software Modules. The Complex Drivers Layer spans from the hardware to the [[RTE]]. It provides the possibility to integrate special purpose functionality, e.g. drivers for specific devices: * which are not specified within AUTOSAR, * with very high timing constrains or * for migration purposes etc. f33cd2456e706ba6395eb3620e417c857a75ebfd 784 782 2014-07-25T08:31:53Z 192.168.2.119 0 wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Basic Software Module#Complex Drivers|Complex Device Drivers]] = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = The Complex Device Driver (CDD) generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with [[Software Component]]s in specific ways and can also interact directly with other Basic Software Modules. The Complex Drivers Layer spans from the hardware to the [[RTE]]. It provides the possibility to integrate special purpose functionality, e.g. drivers for specific devices: * which are not specified within AUTOSAR, * with very high timing constrains or * for migration purposes etc. ca1036305317d1843ee099dbf78fa42216e6d637 787 784 2014-07-25T08:35:29Z 192.168.2.119 0 /* Complex Drivers */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Basic Software Module#Complex Drivers|Complex Device Drivers]] = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = The Complex Device Driver (CDD) generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with [[Software Component]]s in specific ways and can also interact directly with other Basic Software Modules. The Complex Drivers Layer spans from the hardware to the [[RTE]]. It provides the possibility to integrate special purpose functionality, e.g. drivers for specific devices: * which are not specified within AUTOSAR, * with very high timing constrains or * for migration purposes etc. An [[Atomic Software Component]] that on one side interfaces with the [[VFB]] and on the other side directly accesses [[Peripheral Hardware]] and/or [[ECU-Abstraction]] and/or [[MCAL]]. Complex Driver can be accessed via [[AUTOSAR Interface]]s and/or directly by Basic Software Modules ([[BSM]]). This [[SW]] situated below the AUTOSAR [[RTE]]. This software in general is not re-locatable. d27583893b16254d1a6428d6e892ab80bf432d39 804 787 2014-07-25T08:39:13Z 192.168.2.119 0 /* Complex Drivers */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Basic Software Module#Complex Drivers|Complex Device Drivers]] = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = The Complex Device [[Driver]] (CDD) generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with [[Software Component]]s in specific ways and can also interact directly with other Basic Software Modules. The Complex Drivers Layer spans from the hardware to the [[RTE]]. It provides the possibility to integrate special purpose functionality, e.g. drivers for specific devices: * which are not specified within AUTOSAR, * with very high timing constrains or * for migration purposes etc. An [[Atomic Software Component]] that on one side interfaces with the [[VFB]] and on the other side directly accesses [[Peripheral Hardware]] and/or [[ECU-Abstraction]] and/or [[MCAL]]. Complex Driver can be accessed via [[AUTOSAR Interface]]s and/or directly by Basic Software Modules ([[BSM]]). This [[SW]] situated below the AUTOSAR [[RTE]]. This software in general is not re-locatable. a7d6cc5022e4a88369813b10ccbfe2abb89e0a41 0 156 770 173 2014-07-25T06:57:21Z 192.168.2.119 0 Redirected page to [[Basic Software Module#ECU Abstraction Layer]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#ECU Abstraction Layer]] 207f601acdf13f068f3c543cea9e0caaf72de5a1 0 318 772 616 2014-07-25T07:02:26Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Services Layer]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Services Layer]] 38438e1c567f45946505a5b99a0a9357404e2b7a 0 395 774 487 2014-07-25T07:05:07Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Complex Driver]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Complex Driver]] 28629546717434c9222e4613a9eda24d86ef9a93 776 774 2014-07-25T07:37:46Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Complex Drivers]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Complex Drivers]] 48a711c11049c5376f024c66bd6bee32276f1aa7 0 30 775 485 2014-07-25T07:37:11Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Complex Drivers]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Complex Drivers]] 48a711c11049c5376f024c66bd6bee32276f1aa7 0 394 777 486 2014-07-25T07:38:52Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Complex Drivers]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Complex Drivers]] 48a711c11049c5376f024c66bd6bee32276f1aa7 0 570 778 2014-07-25T07:39:24Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Complex Drivers]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Complex Drivers]] 48a711c11049c5376f024c66bd6bee32276f1aa7 0 567 779 745 2014-07-25T07:40:29Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 26 780 739 2014-07-25T07:41:19Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 414 783 529 2014-07-25T08:21:07Z 192.168.2.119 0 wikitext text/x-wiki The Runtime Environment implements the [[VFB]] functionality on a specific [[ECU]] to make [[Software Component]]s independent from the mapping to a specific [[ECU]]. The RTE is a layer providing communication services to the application software (Software Components and/or [[Sensor/Actuator SW-Component]]s). The SW-Cs communicate with other components ([[inter ECU]] and/or [[intra ECU]]) and/or [[service]]s via the RTE. d09a34ef214a5e66fb2060551ea063b60f23b8d7 0 571 785 2014-07-25T08:33:32Z 192.168.2.119 0 Created page with "A driver contains the functionality to control and access an internal or an external hardware device. A driver for an internal device is called '''internal driver''' and is l..." wikitext text/x-wiki A driver contains the functionality to control and access an internal or an external hardware device. A driver for an internal device is called '''internal driver''' and is located in the [[Microcontroller Abstraction Layer]]. 162871451741789bd19b203c7a334c38c64667a6 805 785 2014-07-25T08:41:47Z 192.168.2.119 0 wikitext text/x-wiki A driver contains the functionality to control and access an internal or an external hardware device. A driver for an internal device is called '''internal driver''' and is located in the [[Microcontroller Abstraction Layer]]. A driver for an external device is called '''external driver''' and is located in the [[ECU Abstraction Layer]]. It accesses the external device via drivers of the [[Microcontroller Abstraction Layer]] (MCAL). Exception: The drivers for memory mapped external devices (e.g. external [[flash]] memory) may access the [[microcontroller]] directly. Those external drivers are located in the Microcontroller Abstraction Layer because they are microcontroller dependent. e3b020e4573f3091208a0388d1d32838552b9d30 0 29 786 150 2014-07-25T08:34:55Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Complex Drivers]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Complex Drivers]] 48a711c11049c5376f024c66bd6bee32276f1aa7 0 508 788 679 2014-07-25T08:36:07Z 192.168.2.119 0 wikitext text/x-wiki The CAN [[Driver]] (Can) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 00c007b0aad3dd6aa794ce56b9f6300f40c88984 0 509 789 680 2014-07-25T08:36:33Z 192.168.2.119 0 wikitext text/x-wiki The Ethernet [[Driver]] (Eth) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 9a1aa3faef4f2a56b12a144ab842d0c2c65128e6 0 510 790 681 2014-07-25T08:36:42Z 192.168.2.119 0 wikitext text/x-wiki The FlexRay [[Driver]] (Fr) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f7a3e82346ce9488dde5da9e968ba1e262c96ad2 0 511 791 682 2014-07-25T08:36:53Z 192.168.2.119 0 wikitext text/x-wiki The LIN [[Driver]] (Lin) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 1cc6364597edefc88ec67c7fc10d1863e366a896 0 512 792 683 2014-07-25T08:37:04Z 192.168.2.119 0 wikitext text/x-wiki The TTCAN [[Driver]] (Ttcan) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === e09b9ce0bad972a8465ac41644b5dfb3862f8fb7 0 513 793 684 2014-07-25T08:37:15Z 192.168.2.119 0 wikitext text/x-wiki The SPI Handler [[Driver]] (Spi) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === c58141fffe0329ca49ac20bf8b2c72fe8d2af977 808 793 2014-07-25T08:43:39Z 192.168.2.119 0 wikitext text/x-wiki The SPI [[Handler]] [[Driver]] (Spi) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 6834916c5217ec95327600b3da984d540eb5018d 0 540 794 711 2014-07-25T08:37:25Z 192.168.2.119 0 wikitext text/x-wiki The ADC [[Driver]] (Adc) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 22bcdb24809dc085bbe64d3f6672d66c517c4af2 0 541 795 712 2014-07-25T08:37:34Z 192.168.2.119 0 wikitext text/x-wiki The DIO [[Driver]] (Dio) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === e6b932996437654aaa7729407fbacf546e496580 0 542 796 713 2014-07-25T08:37:43Z 192.168.2.119 0 wikitext text/x-wiki The ICU [[Driver]] (Icu) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === d2c4dc72bbe55205c171b1783d42e2554a16225a 0 543 797 714 2014-07-25T08:37:53Z 192.168.2.119 0 wikitext text/x-wiki The PWM [[Driver]] (Pwm) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 5fd48d1ff1ab428a5f4d60b7f1c0cf1783fe4cd1 0 544 798 715 2014-07-25T08:38:02Z 192.168.2.119 0 wikitext text/x-wiki The Port [[Driver]] (Port) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 293882ccd3f84ace3bd962749adb5a1ee27eabf5 0 546 799 717 2014-07-25T08:38:12Z 192.168.2.119 0 wikitext text/x-wiki The EEPROM [[Driver]] (Eep) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === a166347177921c58dbe04c0d618eea6c557358e1 0 547 800 718 2014-07-25T08:38:22Z 192.168.2.119 0 wikitext text/x-wiki The Flash [[Driver]] (Fls) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === cfc0035033e670e2e041752f385e19a3804ff354 0 555 801 726 2014-07-25T08:38:42Z 192.168.2.119 0 wikitext text/x-wiki The GPT [[Driver]] (Gpt) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 1dfcdc9194bdf0ed94df7030501309367905a698 0 556 802 727 2014-07-25T08:38:51Z 192.168.2.119 0 wikitext text/x-wiki The MCU [[Driver]] (Mcu) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 4478fda9f287bf3d5b4beec61a69e1bcdbe99c36 0 557 803 728 2014-07-25T08:39:00Z 192.168.2.119 0 wikitext text/x-wiki The Watchdog [[Driver]] (Wdg) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === d7c565b057631fe04246c8725f0d817987cf0dd4 0 572 806 2014-07-25T08:43:05Z 192.168.2.119 0 Created page with "A handler is a specific [[interface]] which controls the [[concurrent]], multiple and [[asynchronous]] access of one or multiple [[client]]s to one or more [[driver]]s. I.e. i..." wikitext text/x-wiki A handler is a specific [[interface]] which controls the [[concurrent]], multiple and [[asynchronous]] access of one or multiple [[client]]s to one or more [[driver]]s. I.e. it performs buffering, queuing, arbitration, multiplexing. The handler does not change the content of the data. 031fe6097aada8695385cde292ef08c344362a2b 0 244 807 283 2014-07-25T08:43:23Z 192.168.2.119 0 wikitext text/x-wiki In the case of a [[Category 2 interrupt]], the [[ISR]] is synonymous with Interrupt [[Handler]]. In the case of [[Category 1 interrupt]] the Interrupt Handler is the function called by the [[hardware interrupt vector]]. In both cases the Interrupt handler is the user code that is normally a part of the [[BSW module]]. So the Interrupt Handler is a user level piece of code. 30df15cdb80bdcff694eaeed7eae95538f439592 0 573 809 2014-07-25T08:45:11Z 192.168.2.119 0 Created page with "A manager offers specific [[service]]s for multiple [[client]]s. It is needed in all cases where pure handler functionality is not enough to abstract from multiple clients. Be..." wikitext text/x-wiki A manager offers specific [[service]]s for multiple [[client]]s. It is needed in all cases where pure handler functionality is not enough to abstract from multiple clients. Besides handler functionality, a manager can evaluate and change or adapt the content of the data. In general, managers are located in the [[Services Layer]]. fc185d40061663ff5cc5aaeff55a577c804a4d5f 0 448 810 760 2014-07-25T08:45:22Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Event [[Manager]] (DEM) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus 6ad42d6a7a9a30fd135adf7f7e2c93897a546da1 0 452 811 761 2014-07-25T08:45:32Z 192.168.2.119 0 wikitext text/x-wiki The Function Inhibition [[Manager]] (FIM) is a [[Basic Software Module]] of the [[Diagnostic Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Fim_GetFunctionPermission === [[Standardized Interface]] === Fim_DemTriggerOnEventStatus d23441cf294351280721923c77c11cd13f0ff833 0 524 812 695 2014-07-25T08:45:40Z 192.168.2.119 0 wikitext text/x-wiki The CAN State [[Manager]] (CanSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 12cee7b5a5a4a7394b8fd89e5126bb399523c888 0 526 813 697 2014-07-25T08:45:51Z 192.168.2.119 0 wikitext text/x-wiki The Ethernet State [[Manager]] (EthSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f4ad40c860d9e350a0543637374dd7184a915418 0 530 814 701 2014-07-25T08:45:59Z 192.168.2.119 0 wikitext text/x-wiki The FlexRay State [[Manager]] (FrSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 93580a844a2954f3f756252f57e9c5a935c6fb5b 0 533 815 704 2014-07-25T08:46:09Z 192.168.2.119 0 wikitext text/x-wiki The LIN State [[Manager]] (LinSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === d81e8c9c19575b0e053e943c6ea97e8ccf85f963 0 539 816 710 2014-07-25T08:46:21Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Communication [[Manager]] (Dcm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === aa7f180a917a510b712ad052446b102fee671d68 0 553 817 724 2014-07-25T08:46:30Z 192.168.2.119 0 wikitext text/x-wiki The NVRAM [[Manager]] (NvM) is a [[Basic Software Module]] of the [[Memory Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 41897828a5d89e989c18532e8cf61bf6d83537a4 0 559 818 730 2014-07-25T08:46:40Z 192.168.2.119 0 wikitext text/x-wiki The COM [[Manager]] (ComM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 3f445010a7fcd2678e9010523e66111661238fa5 0 560 819 731 2014-07-25T08:47:06Z 192.168.2.119 0 wikitext text/x-wiki The BSW Mode [[Manager]] (BswM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 2f48ef6b6564d793ca517965ee68ce2218d1fb0c 0 561 820 732 2014-07-25T08:47:17Z 192.168.2.119 0 wikitext text/x-wiki The Crypto Service [[Manager]] (Csm) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 29fe2f09d3c8110ec2a3245a84e7cd4a2c0663c7 0 562 821 733 2014-07-25T08:47:27Z 192.168.2.119 0 wikitext text/x-wiki The ECU State [[Manager]] (EcuM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 09010f8b7cfb325bf23d9e4c1cc7434463e37bab 0 563 822 734 2014-07-25T08:47:37Z 192.168.2.119 0 wikitext text/x-wiki The Synchronized Time-Base [[Manager]] (StbM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 81f95ce5faec10aa39f60a188877656d86252f1f 0 564 823 735 2014-07-25T08:47:46Z 192.168.2.119 0 wikitext text/x-wiki The Watchdog [[Manager]] (WdgM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === c42e959dbc627d0108abdb2fea0eaeab77d1ac40 0 155 824 171 2014-07-25T08:53:26Z 192.168.2.119 0 wikitext text/x-wiki A functional and complete description of a specific [[communication stack]] in terms of data structures, [[service|services]], behavioral state-machines, error handling. [[E2E]] Profiles are defined in AUTOSAR [[E2E Library]]. An E2E Profile is configurable by runtime parameters. A specific set of runtime parameters is called E2E profile variant. In order to reach [[interoperability]], the application developers should use the E2E profile variants defined in the E2E [[library]]. 06abbde603c798f59ff4dc5960e6bee29dfe263a 0 574 825 2014-07-25T08:53:39Z 192.168.2.119 0 Redirected page to [[Libraries]] wikitext text/x-wiki #REDIRECT [[Libraries]] 6a829a2b91a93f8ca2fcec860e9cb14e38ce15cf 0 365 826 429 2014-07-25T08:53:53Z 192.168.2.119 0 wikitext text/x-wiki Extended Mathematical [[library]] – Fixed point 5bb1e6fd3fca97723e074b9df95cdb2fe5e99799 0 575 827 2014-07-25T09:00:46Z 192.168.2.119 0 Created page with "Libraries are a collection of functions for related purposes. They * can be called by [[BSW module]]s (that including the [[RTE]]), [[SW-C]]s, libraries or integration code * ..." wikitext text/x-wiki Libraries are a collection of functions for related purposes. They * can be called by [[BSW module]]s (that including the [[RTE]]), [[SW-C]]s, libraries or integration code * run in the [[context]] of the caller in the same [[protection environment]] * can only call libraries * are [[re-entrant]] * do not have internal states * do not require any initialization * are [[synchronous]], i.e. they do not have wait points The following libraries are specified: * [[EFx Library|Fixed point mathematical]], * [[BFx Library|Floating point mathematical]], * Interpolation for fixed point data, * Interpolation for floating point data, * Bit handling, * [[E2E Library|E2E communication]], * [[CRC Library|CRC calculation]], * Extended functions (e.g. 64bits calculation, filtering, etc.) and * [[Crypto Abstraction Library|Crypto]] [[IFl Library]] [[MFl Library]] [[MFx Library]] [[IFx Library]] 46474a3f25f613986cfa05f8cbf36d75f7070a45 0 59 828 746 2014-07-25T09:01:20Z 192.168.2.119 0 Redirected page to [[Basic Software Module#Microcontroller Abstraction Layer]] wikitext text/x-wiki #REDIRECT [[Basic Software Module#Microcontroller Abstraction Layer]] c3a3f8fa5bc17054dbcd3c8fe9d1cbffdb783f0c 0 545 829 716 2014-07-25T09:29:02Z 192.168.2.119 0 wikitext text/x-wiki The IO HW Abstraction is a [[Basic Software Module]] of the [[I/O HW Abstraction]] layer. It abstracts from the location of peripheral I/O devices (on-chip or on-board) and the [[ECU]] hardware layout (e.g. [[uC]] pin connections and signal level inversions). The I/O Hardware Abstraction does not abstract from the sensors/actuators! The different I/O devices might be accessed via [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 2a82dd9076fd515dfd2c21b4df66035ccb72b174 830 829 2014-07-25T09:30:18Z 192.168.2.119 0 wikitext text/x-wiki The IO HW Abstraction is a [[Basic Software Module]] of the [[I/O HW Abstraction]] layer. It abstracts from the location of peripheral I/O devices (on-chip or on-board) and the [[ECU]] hardware layout (e.g. [[uC]] pin connections and signal level inversions). The I/O Hardware Abstraction does not abstract from the sensors/actuators! The different I/O devices might be accessed via [[I/O Drivers]]. === [[AUTOSAR Interface]] === Project (resp. hardware) specific. === [[Standardized AUTOSAR Interface]] === none === [[Standardized Interface]] === none e26b703d16aa4fd5c927d12e02acc7c4e8cfa561 0 387 831 476 2014-07-25T10:02:02Z 192.168.2.119 0 wikitext text/x-wiki The Sensor-Actuator Software Component is an [[Atomic Software Component]] that handles the specifics of a [[sensor]] and/or [[actuator]]. It directly interacts with the [[ECU Abstraction Layer]]. e1a500deb38c7dd460bf72b4645b7cee2dfdc14b 0 576 832 2014-07-25T10:04:47Z 192.168.2.119 0 Created page with "The Inter OsApplication Communication (IOC), as shown in the figure, provides communication services which can be accessed by clients which need to communicate across OS-Appli..." wikitext text/x-wiki The Inter OsApplication Communication (IOC), as shown in the figure, provides communication services which can be accessed by clients which need to communicate across OS-Application boundaries on the same [[ECU]]. The IOC is part of the [[OS]]. 150a891741a032675d3722f3fcb2047cf4b0d8dc 0 577 833 2014-07-25T10:05:28Z 192.168.2.119 0 Redirected page to [[IOC]] wikitext text/x-wiki #REDIRECT [[IOC]] 5de114dec975dc2b4a58c29dd4a03199eed1a1c8 0 240 834 278 2014-07-25T10:19:45Z 192.168.2.119 0 wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. There are three different interfaces defined in: * [[AUTOSAR Interface]] * [[Standardized AUTOSAR Interface]] * [[Standardized Interface]] d7fbccd1715452cc382582502d891257b28037cf 835 834 2014-07-25T10:21:25Z 192.168.2.119 0 wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. There are three different interfaces defined in: * [[AUTOSAR Interface]] * [[Standardized AUTOSAR Interface]] * [[Standardized Interface]] ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf page 59 "Components and interfaces view (simplified)".'' be2b001fb615ad8fd19163cbeaf240bdd3f94604 836 835 2014-07-25T10:27:39Z 192.168.2.119 0 wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. There are three different interfaces defined in: * [[AUTOSAR Interface]] * [[Standardized AUTOSAR Interface]] * [[Standardized Interface]] ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf * page 59 "Components and interfaces view (simplified)".'' * page 60 "General Interfacing Rules" c9731c96b0d3f3536d12dae7333c6e17ace32d04 0 578 837 2014-07-25T10:32:24Z 192.168.2.119 0 Created page with "The [[Basic Software]] supports the following configuration classes: == Pre-compile time == * [[Preprocessor]] instructions * Code generation (selection or synthetization) ==..." wikitext text/x-wiki The [[Basic Software]] supports the following configuration classes: == Pre-compile time == * [[Preprocessor]] instructions * Code generation (selection or synthetization) == Link time == * Constant data outside the module; the data can be configured after the module has been compiled == Post-build time == * Loadable constant data outside the module. Very similar to Link Time, but the data is located in a specific memory segment that allows reloading (e.g. re-flashing in [[ECU]] production line) * Single or multiple configuration sets can be provided. In case that multiple configuration sets are provided, the actually used configuration set is to be specified at runtime. c97fc20e895d7a1a70ff90d542ee268e2c012608 0 31 839 34 2014-07-25T11:07:21Z 192.168.2.119 0 wikitext text/x-wiki Main features of the COM module are * Provision of signal oriented data interface for the [[RTE]] * Packing of AUTOSAR signals to [[I-PDU]]s to be transmitted * Unpacking of received I-PDUs and provision of received signals to RTE * [[Routing]] of signals from received I-PDUs into I-PDUs to become transmitted * Routing of signal groups from received I-PDUs into I-PDUs to become transmitted * Communication transmission control (start/ stop of I-PDU groups) * Replications of send requests * Guarantee of minimum distances between transmit I-PDUs * Monitoring of receive signals (signals timeout) * Filter mechanisms for incoming signals * Different notification mechanisms * Provision of init values and update indications * [[Byte order]] conversion * Sign extension * Support of two different transmission modes per I-PDU * Signal based gateway * Support of large and dynamic length data types * Support of I-PDU counters and I-PDU replication 985622fc774955c32cf6964fda8dc77800898856 843 839 2014-07-25T11:18:06Z 192.168.2.119 0 wikitext text/x-wiki Main features of the COM module are * Provision of signal oriented data interface for the [[RTE]] * Packing of AUTOSAR signals to [[I-PDU]]s to be transmitted * Unpacking of received I-PDUs and provision of received signals to RTE * [[Routing]] of signals from received I-PDUs into I-PDUs to become transmitted * Routing of signal groups from received I-PDUs into I-PDUs to become transmitted * Communication transmission control (start/ stop of I-PDU groups) * Replications of send requests * Guarantee of minimum distances between transmit I-PDUs * Monitoring of receive signals (signals timeout) * Filter mechanisms for incoming signals * Different notification mechanisms * Provision of init values and update indications * [[Byte order]] conversion * Sign extension * Support of two different transmission modes per I-PDU * Signal based gateway * Support of large and dynamic length data types * Support of I-PDU counters and I-PDU replication The AUTOSAR COM module provides the following ComFilterAlgorithms: * ALWAYS * NEVER * MASKED_NEW_EQUALS_X * MASKED_NEW_DIFFERS_X * MASKED_NEW_DIFFERS_MASKED_OLD * NEW_IS_WITHIN * NEW_IS_OUTSIDE * ONE_EVERY_N 3a3ba25d0518a3e51f4862dd7d4c0bce3b9db822 0 579 840 2014-07-25T11:07:44Z 192.168.2.119 0 Created page with "Deadline Monitoring" wikitext text/x-wiki Deadline Monitoring 33a1497d0dfc3b2b345ef87aaf10686d15f185f7 0 580 841 2014-07-25T11:08:09Z 192.168.2.119 0 Created page with "Minimum Delay Timer" wikitext text/x-wiki Minimum Delay Timer a67d593faf01c248bba272103b4d4c711fc6408e 0 581 842 2014-07-25T11:08:44Z 192.168.2.119 0 Created page with "Transmission Mode" wikitext text/x-wiki Transmission Mode ea0709051b5caa96e5c078e4287fd38d634a157e 0 582 844 2014-07-25T13:14:08Z 192.168.2.119 0 Created page with "In the configuration of an [[ECU]] there is information which needs to be shared between multiple [[BSW Module]]s. Since it can not be defined who owns this shared information..." wikitext text/x-wiki In the configuration of an [[ECU]] there is information which needs to be shared between multiple [[BSW Module]]s. Since it can not be defined who owns this shared information the virtual module EcuC has been introduced to the AUTOSAR [[ECU Configuration]] Parameter Definition. 6c4f6efd54b9811b04636aab4f637368d4ae351a 0 583 845 2014-07-30T06:21:40Z 192.168.2.171 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 449 846 804 2014-07-30T06:22:01Z 192.168.2.171 0 /* Complex Drivers */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Basic Software Module#Complex Drivers|Complex Device Drivers]] = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = The Complex Device [[Driver]] (CDD) generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with [[Software Component]]s in specific ways and can also interact directly with other Basic Software Modules. The Complex Drivers Layer spans from the hardware to the [[RTE]]. It provides the possibility to integrate special purpose functionality, e.g. drivers for specific devices: * which are not specified within AUTOSAR, * with very high timing constrains or * for migration purposes etc. An [[Atomic Software Component]] that on one side interfaces with the [[VFB]] and on the other side directly accesses [[Peripheral Hardware]] and/or [[ECU-Abstraction]] and/or [[MCAL]]. Complex Driver can be accessed via [[AUTOSAR Interface]]s and/or directly by Basic Software Modules (BSM). This [[SW]] situated below the AUTOSAR [[RTE]]. This software in general is not re-locatable. 7ace7c36db8de8d071d013211df84771a583a2b8 847 846 2014-07-30T06:22:30Z 192.168.2.171 0 /* Complex Drivers */ wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Basic Software Module#Complex Drivers|Complex Device Drivers]] = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[Flash EEPROM Emulation]] (Fee) * [[Memory Abstraction Interface]] (MemIf) * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = The Complex Device [[Driver]] (CDD) generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with [[Software Component]]s in specific ways and can also interact directly with other Basic Software Modules. The Complex Drivers Layer spans from the hardware to the [[RTE]]. It provides the possibility to integrate special purpose functionality, e.g. drivers for specific devices: * which are not specified within AUTOSAR, * with very high timing constrains or * for migration purposes etc. An [[Atomic Software Component]] that on one side interfaces with the [[VFB]] and on the other side directly accesses [[Peripheral Hardware]] and/or [[ECU-Abstraction]] and/or [[MCAL]]. Complex Driver can be accessed via [[AUTOSAR Interface]]s and/or directly by Basic Software Modules (BSWM). This [[SW]] situated below the AUTOSAR [[RTE]]. This software in general is not re-locatable. f1d518c0c29fc114f5182ef412cbd55200ae38a3 0 234 848 271 2014-07-30T15:53:49Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 255 849 296 2014-07-30T15:54:33Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 584 850 2014-07-30T16:03:17Z 192.168.2.119 0 Created page with "Power train code" wikitext text/x-wiki Power train code 7c34c69fcac5e3737323c2085d553345fbd64ee9 0 585 851 2014-07-30T16:04:07Z 192.168.2.119 0 Created page with "Freeze frame is defined as a record of data ([[DID]]s/[[PID]]s). Freeze frames are the same as SnapShotRecords in [[ISO 14229-1]]." wikitext text/x-wiki Freeze frame is defined as a record of data ([[DID]]s/[[PID]]s). Freeze frames are the same as SnapShotRecords in [[ISO 14229-1]]. 89268c63c4a0e15e10bd8c2d9d5dc23acb6de634 0 586 852 2014-07-30T16:05:08Z 192.168.2.119 0 Created page with "An Operating Cycle is the base of the event qualifying and also [[Dem]] scheduling (e.g. ignition key off-on cycles, driving cycles, etc.)" wikitext text/x-wiki An Operating Cycle is the base of the event qualifying and also [[Dem]] scheduling (e.g. ignition key off-on cycles, driving cycles, etc.) 2fd1cc3819cf3ed3506d0e68b4f50dad119617d7 0 587 853 2014-07-30T16:06:14Z 192.168.2.119 0 Created page with "Unlearning/deleting of a no longer failed event/[[DTC]] after a defined number of [[operation cycle]]s from [[event memory]]." wikitext text/x-wiki Unlearning/deleting of a no longer failed event/[[DTC]] after a defined number of [[operation cycle]]s from [[event memory]]. 240c6937de2c5e0968d610878ee2618d70600ba0 0 588 854 2014-07-30T16:10:57Z 192.168.2.119 0 Created page with "The phrase 'healing' is used in the context of [[Failure Memory]] and [[DTC]]s. After a specified number of [[Operating cycle]]s a DTC is completely cleared from Failure Memor..." wikitext text/x-wiki The phrase 'healing' is used in the context of [[Failure Memory]] and [[DTC]]s. After a specified number of [[Operating cycle]]s a DTC is completely cleared from Failure Memory. The failure is then 'healed'. 88197fdf0063e1dbe9a6cdf5d5427542e2308902 0 589 855 2014-07-30T16:12:15Z 192.168.2.119 0 Created page with "Data Identifier" wikitext text/x-wiki Data Identifier cfc34ee295595cbed5dceaf6b32c27c7d80f557c 0 590 856 2014-07-30T16:12:51Z 192.168.2.119 0 Redirected page to [[Aging]] wikitext text/x-wiki #REDIRECT [[Aging]] 6fd81dd469dc97baccd36ce3affec3a62d480760 0 591 857 2014-07-30T16:13:00Z 192.168.2.119 0 Created page with "Diagnostic Trouble Code" wikitext text/x-wiki Diagnostic Trouble Code 7b49af26b1bd1f5819ef7109dd6fb5400c4f19ff 0 592 858 2014-07-30T16:14:46Z 192.168.2.119 0 Created page with "[[Fault]] Detection Counter" wikitext text/x-wiki [[Fault]] Detection Counter 6e785618ead5548c937cc540a72102c0416fa31d 0 593 859 2014-07-30T16:15:58Z 192.168.2.119 0 Created page with "International Standardization Organization see [http://www.ISO.org]" wikitext text/x-wiki International Standardization Organization see [http://www.ISO.org] 7dfce4a12a54882474d5fa1a00617c2ff3653c0f 0 594 860 2014-07-30T16:16:15Z 192.168.2.119 0 Created page with "In Use Monitoring Performance Ratio" wikitext text/x-wiki In Use Monitoring Performance Ratio 44f98a5156c0ff1ea539f909a30005ad68426af2 0 595 861 2014-07-30T16:16:37Z 192.168.2.119 0 Created page with "Malfunction Indication Light" wikitext text/x-wiki Malfunction Indication Light ebc1269e8defbf10bc910ffe90ac86b7ed726e03 0 596 862 2014-07-30T16:16:57Z 192.168.2.119 0 Created page with "Onboard Diagnostics" wikitext text/x-wiki Onboard Diagnostics e8f42926a309a35b00be80253a963479d671e8fc 0 597 863 2014-07-30T16:18:19Z 192.168.2.119 0 Created page with "Parameter Identification. See also [[DID]]." wikitext text/x-wiki Parameter Identification. See also [[DID]]. d5db5de0ebefac5cfcd90b06d676913960c477b1 0 598 864 2014-07-30T16:18:50Z 192.168.2.119 0 Created page with "[[synchronous]] [[server]] call point" wikitext text/x-wiki [[synchronous]] [[server]] call point 5803d0f4461284ca2840214d256fd57f6aef7269 0 599 865 2014-07-30T16:19:03Z 192.168.2.119 0 Created page with "Unified Diagnostic Services" wikitext text/x-wiki Unified Diagnostic Services 40f746cceab14bf00dbf45148847d17986de9552 0 452 866 811 2014-07-30T20:27:21Z 192.168.2.119 0 wikitext text/x-wiki The Function Inhibition [[Manager]] (FIM) is a [[Basic Software Module]] of the [[Diagnostic Services]]. The FiM stands for the evaluation and assignment of events to the required actions for [[Software Component]]s (e.g. inhibition of specific “Monitors”). === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Fim_GetFunctionPermission === [[Standardized Interface]] === Fim_DemTriggerOnEventStatus f7998ce905ae272ad53de78b61c7ba6bd5db72ff 0 565 867 756 2014-07-30T20:27:49Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Log and Trace (DLT) is a [[Basic Software Module]] of the [[Diagnostic Services]]. It provides a generic Logging and Tracing functionality. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 4723807e3c434cf89d12e072a778f58fe60bd007 0 539 868 816 2014-07-30T20:29:08Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Communication [[Manager]] (Dcm) is a [[Basic Software Module]] of the [[Communication Services]]. It is in charge of the communication path and execution of [[diagnostic service]] resulting in the processing of [[diagnostic requests]] from an external [[tester]] or onboard test system. It forwards requests coming from an external diagnostic scan tool and is further responsible for assembly of response messages ([[DTC]], status information, etc.) which will be transferred to the external diagnostic scan tool afterwards. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === e097ab113d6c3e672e1c407239e832878de1ab5e 0 562 869 821 2014-07-30T20:30:03Z 192.168.2.119 0 wikitext text/x-wiki The ECU State [[Manager]] (EcuM) is a [[Basic Software Module]] of the [[System Services]]. It is responsible for the basic initialization and de-initialization of basic software components. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 908ab533aaaaede281ea397dbd0680de8a67c0eb 0 448 870 810 2014-07-30T20:32:48Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the events detected by diagnostic monitors in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus 4f99cae817cec326ec622229ce8fc8d2d054a477 871 870 2014-07-30T20:34:11Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the [[diagnostic event]]s detected by [[diagnostic monitor]]s in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus 4d91f37a041ef1da84a8a634c4985b7d9ffa5de8 875 871 2014-07-30T22:01:38Z 192.168.2.119 0 wikitext text/x-wiki The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the [[diagnostic event]]s detected by [[diagnostic monitor]]s in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus === [[Container]]s and configuration parameters === Format: ''Container / Parameter {Multiplicity; Type; ConfigurationClass; Range}'' ''Description'' ==== DemConfigSet ==== Multiplicity:=1 ==== DemGeneral ==== Multiplicity:=1 DemGeneral/'''DemAgingCycleCounterProcessing''' {1; [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the aging counter is calculated Dem-internally or provided via [[Dem_SetAgingCycleCounterValue]]. * DEM_PROCESS_AGINGCTR_EXTERN: based on [[API]] [[Dem_SetAgingCycleCounterValue]] * DEM_PROCESS_AGINGCTR_INTERN: based on reported cycle states DemGeneral/'''DemBswErrorBufferSize''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0 .. 255} Maximum number of elements in buffer for handling of BSW errors. 464a7b63611623dffa5e11547924da5e36150c88 876 875 2014-07-30T22:37:59Z Oliver 1 /* DemGeneral */ wikitext text/x-wiki The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the [[diagnostic event]]s detected by [[diagnostic monitor]]s in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus === [[Container]]s and configuration parameters === Format: ''Container / Parameter {Multiplicity; Type; ConfigurationClass; Range}'' ''Description'' ==== DemConfigSet ==== Multiplicity:=1 ==== DemGeneral ==== Multiplicity:=1 DemGeneral/'''DemAgingCycleCounterProcessing''' {1; [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the aging counter is calculated Dem-internally or provided via [[Dem_SetAgingCycleCounterValue]]. * DEM_PROCESS_AGINGCTR_EXTERN: based on [[API]] [[Dem_SetAgingCycleCounterValue]] * DEM_PROCESS_AGINGCTR_INTERN: based on reported cycle states DemGeneral/'''DemBswErrorBufferSize''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of elements in buffer for handling of BSW errors. DemGeneral/'''DemClearDTCBehavior''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} Defines the clearing process of diagnostic information for volatile and [[non-volatile memory]] and the positive response handling for the [[Dcm]] module. * DEM_CLRRESP_NONVOLATILE_FINISH: Return DEM_CLEAR_OK after volatile and non-volatile event memory data cleared. * DEM_CLRRESP_NONVOLATILE_TRIGGER: Return DEM_CLEAR_OK after volatile event memory data cleared and non-volatile event memory clearing is triggered * DEM_CLRRESP_VOLATILE: Return DEM_CLEAR_OK after volatile event memory data cleared DemGeneral/'''DemDTCSuppressionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for [[DTC]] suppression is enabled or not. * TRUE: DTC suppression support is enabled * FALSE: DTC suppression support is disabled DemGeneral/'''DemDebounceCounterBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for counter based debouncing is enabled or not. * TRUE: counter based debouncing support is enabled * FALSE: counter based debouncing support is disabled 3786aa343cbebc030f634a3090fe67a1fe9b15af 877 876 2014-08-01T07:58:08Z Oliver 1 /* Containers and configuration parameters */ wikitext text/x-wiki The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the [[diagnostic event]]s detected by [[diagnostic monitor]]s in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus === [[Container]]s and configuration parameters === Format: ''Container / Parameter {Multiplicity; Type; ConfigurationClass; Range}'' ''Description'' ==== DemConfigSet ==== Multiplicity:=1 ==== DemGeneral ==== Multiplicity:=1 DemGeneral/'''DemAgingCycleCounterProcessing''' {1; [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the aging counter is calculated Dem-internally or provided via [[Dem_SetAgingCycleCounterValue]]. * DEM_PROCESS_AGINGCTR_EXTERN: based on [[API]] [[Dem_SetAgingCycleCounterValue]] * DEM_PROCESS_AGINGCTR_INTERN: based on reported cycle states DemGeneral/'''DemBswErrorBufferSize''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of elements in buffer for handling of BSW errors. DemGeneral/'''DemClearDTCBehavior''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} Defines the clearing process of diagnostic information for volatile and [[non-volatile memory]] and the positive response handling for the [[Dcm]] module. * DEM_CLRRESP_NONVOLATILE_FINISH: Return DEM_CLEAR_OK after volatile and non-volatile event memory data cleared. * DEM_CLRRESP_NONVOLATILE_TRIGGER: Return DEM_CLEAR_OK after volatile event memory data cleared and non-volatile event memory clearing is triggered * DEM_CLRRESP_VOLATILE: Return DEM_CLEAR_OK after volatile event memory data cleared DemGeneral/'''DemDTCSuppressionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for [[DTC]] suppression is enabled or not. * TRUE: DTC suppression support is enabled * FALSE: DTC suppression support is disabled DemGeneral/'''DemDebounceCounterBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for counter based debouncing is enabled or not. * TRUE: counter based debouncing support is enabled * FALSE: counter based debouncing support is disabled DemGeneral/'''DemDebounceTimeBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for time based debouncing is enabled or not. * TRUE: time based debouncing support is enabled * FALSE: time based debouncing support is disabled DemGeneral/'''DemDevErrorDetect''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the Development Error Detection and Notification. * TRUE: Development Error Detection and Notification activated * FALSE: DevelopmentError Detection and Notification deactivated DemGeneral/'''DemDtcStatusAvailabilityMask''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Mask for the supported [[DTC]] status bits by the Dem. This mask is used by [[UDS]] service 0x19. DemGeneral/'''DemEnableConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for enable conditions is enabled or not. * TRUE: support for enable conditions is enabled * FALSE: support for enable conditions is disabled DemGeneral/'''DemEventCombinationSupport''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of event combination supported by the Dem. * DEM_EVCOMB_DISABLED: No event combination supported * DEM_EVCOMB_TYPE1: Event combination Type 1 enabled * DEM_EVCOMB_TYPE2: Event combination Type 2 enabled DemGeneral/'''DemEventDisplacementSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for event displacement is enabled or not. * TRUE: event displacement support is enabled * FALSE: event displacement support is disabled DemGeneral/'''DemExtendedDataCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the extended data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of extended data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of extended data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemFreezeFrameCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the freeze frame data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of freeze frame data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of freeze frame data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemHeaderFileInclusion''' {0..*, [[EcucStringParamDef|String]]; [[Pre-compile time|Pre]]} Name of the header file(s) to be included by the Dem module containing the used C-[[callback]] declarations. DemGeneral/'''DemImmediateNvStorageLimit''' {0..1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} This parameter defines the maximum number of occurrences, a specific event memory entry is allowed, to be stored in [[NVRAM]] immediately (refer to [[DemImmediateNvStorage]]). DemGeneral/'''DemMaxNumberEventEntryMirror''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[mirror memory]]. DemGeneral/'''DemMaxNumberEventEntryPermanent''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[permanent memory]]. The assignment of an event to this memory type is dynamic and used for emission-related events only. DemGeneral/'''DemMaxNumberEventEntryPrimary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} Maximum number of events which can be stored in the [[primary memory]]. DemGeneral/'''DemMaxNumberEventEntrySecondary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[secondary memory]]. DemGeneral/'''DemMaxNumberPrestoredFF''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Defines the maximum number for pre-stored [[freeze frame]]s. If set to 0, then freeze frame pre-storage is not supported by the [[ECU]]. DemGeneral/'''DemOBDSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines whether [[OBD]] is supported or not. 796734dadb0f698d06d283e07a646fc7bcba9241 878 877 2014-08-01T08:14:00Z Oliver 1 /* Containers and configuration parameters */ wikitext text/x-wiki The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the [[diagnostic event]]s detected by [[diagnostic monitor]]s in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus === [[Container]]s and configuration parameters === Format: ''Container / Parameter {Multiplicity; Type; ConfigurationClass; Range}'' ''Description'' ==== DemConfigSet ==== Multiplicity:=1 ==== DemGeneral ==== Multiplicity:=1 DemGeneral/'''DemAgingCycleCounterProcessing''' {1; [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the aging counter is calculated Dem-internally or provided via [[Dem_SetAgingCycleCounterValue]]. * DEM_PROCESS_AGINGCTR_EXTERN: based on [[API]] [[Dem_SetAgingCycleCounterValue]] * DEM_PROCESS_AGINGCTR_INTERN: based on reported cycle states DemGeneral/'''DemBswErrorBufferSize''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of elements in buffer for handling of BSW errors. DemGeneral/'''DemClearDTCBehavior''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} Defines the clearing process of diagnostic information for volatile and [[non-volatile memory]] and the positive response handling for the [[Dcm]] module. * DEM_CLRRESP_NONVOLATILE_FINISH: Return DEM_CLEAR_OK after volatile and non-volatile event memory data cleared. * DEM_CLRRESP_NONVOLATILE_TRIGGER: Return DEM_CLEAR_OK after volatile event memory data cleared and non-volatile event memory clearing is triggered * DEM_CLRRESP_VOLATILE: Return DEM_CLEAR_OK after volatile event memory data cleared DemGeneral/'''DemDTCSuppressionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for [[DTC]] suppression is enabled or not. * TRUE: DTC suppression support is enabled * FALSE: DTC suppression support is disabled DemGeneral/'''DemDebounceCounterBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for counter based debouncing is enabled or not. * TRUE: counter based debouncing support is enabled * FALSE: counter based debouncing support is disabled DemGeneral/'''DemDebounceTimeBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for time based debouncing is enabled or not. * TRUE: time based debouncing support is enabled * FALSE: time based debouncing support is disabled DemGeneral/'''DemDevErrorDetect''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the Development Error Detection and Notification. * TRUE: Development Error Detection and Notification activated * FALSE: DevelopmentError Detection and Notification deactivated DemGeneral/'''DemDtcStatusAvailabilityMask''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Mask for the supported [[DTC]] status bits by the Dem. This mask is used by [[UDS]] service 0x19. DemGeneral/'''DemEnableConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for enable conditions is enabled or not. * TRUE: support for enable conditions is enabled * FALSE: support for enable conditions is disabled DemGeneral/'''DemEventCombinationSupport''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of event combination supported by the Dem. * DEM_EVCOMB_DISABLED: No event combination supported * DEM_EVCOMB_TYPE1: Event combination Type 1 enabled * DEM_EVCOMB_TYPE2: Event combination Type 2 enabled DemGeneral/'''DemEventDisplacementSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for event displacement is enabled or not. * TRUE: event displacement support is enabled * FALSE: event displacement support is disabled DemGeneral/'''DemExtendedDataCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the extended data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of extended data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of extended data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemFreezeFrameCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the freeze frame data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of freeze frame data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of freeze frame data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemHeaderFileInclusion''' {0..*, [[EcucStringParamDef|String]]; [[Pre-compile time|Pre]]} Name of the header file(s) to be included by the Dem module containing the used C-[[callback]] declarations. DemGeneral/'''DemImmediateNvStorageLimit''' {0..1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} This parameter defines the maximum number of occurrences, a specific event memory entry is allowed, to be stored in [[NVRAM]] immediately (refer to [[DemImmediateNvStorage]]). DemGeneral/'''DemMaxNumberEventEntryMirror''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[mirror memory]]. DemGeneral/'''DemMaxNumberEventEntryPermanent''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[permanent memory]]. The assignment of an event to this memory type is dynamic and used for emission-related events only. DemGeneral/'''DemMaxNumberEventEntryPrimary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} Maximum number of events which can be stored in the [[primary memory]]. DemGeneral/'''DemMaxNumberEventEntrySecondary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[secondary memory]]. DemGeneral/'''DemMaxNumberPrestoredFF''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Defines the maximum number for pre-stored [[freeze frame]]s. If set to 0, then freeze frame pre-storage is not supported by the [[ECU]]. DemGeneral/'''DemOBDSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines whether [[OBD]] is supported or not. DemGeneral/'''DemOccurrenceCounterProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines the consideration of the fault confirmation process for the occurrence counter. For [[OBD]] and mixed systems (OBD/non OBD, refer to [[DemOBDSupport]]) the fault confirmation process must not be considered. * DEM_PROCESS_OCCCTR_CDTC: the occurrence counter is triggered by the TestFailed bit only, but the fault confirmation is not considered * DEM_PROCESS_OCCCTR_TF: the occurrence counter is triggered after the fault confirmation was successful DemGeneral/'''DemOperationCycleProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[operation cycle]]s are triggered by DEM_CYCLE_STATE_START or collecting an external counter value, which results in respective state changes. * DEM_PROCESS_OPCYC_COUNTER: operation cycle processing is based on [[API]] [[Dem_SetOperationCycleCntValue]] * DEM_PROCESS_OPCYC_STATE: operation cycle processing is based on API [[Dem_SetOperationCycleState]] DemGeneral/'''DemOperationCycleStatusStorage''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the operation cycle state is available over the [[power cycle]] (stored non-volatile) or not. * TRUE: the operation cycle state is stored [[non-volatile]] * FALSE: the operation cycle state is only stored [[volatile]] DemGeneral/'''DemPTOSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether [[PTO]] support (and therefore [[PID]] $1E support) is enabled or not. DemGeneral/'''DemStatusBitHandlingTestFailedSinceLastClear''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[aging]] and displacement mechanism shall be applied to the "[[TestFailedSinceLastClear]]" status bits. * DEM_STATUS_BIT_AGING_AND_DISPLACEMENT: the "TestFailedSinceLastClear" status bits are reset to 0, if aging or displacement applies (like done for the "[[ConfirmedDTC]]" status bits) * DEM_STATUS_BIT_NORMAL: aging and displacement has no impact on the "TestFailedSinceLastClear" status bits DemGeneral/'''DemStatusBitStorageTestFailed''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the permanent storage of the "[[TestFailed]]" status bits. * TRUE: storage activated * FALSE: storage deactivated DemGeneral/'''DemStorageConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for storage conditions is enabled or not. * TRUE: support for storage conditions is enabled * FALSE: support for storage conditions is disabled DemGeneral/'''DemTaskTime''' {1, [[EcucFloatParamDef|Float]]; [[Pre-compile time|Pre]]; 0..0.1} Allow to configure the time for the periodic [[cyclic task]]. Please note: This configuration value shall be equal to the value in the [[Basic Software Scheduler]] configuration of the [[RTE]] module. The AUTOSAR configuration standard is to use [[SI unit]]s, so this parameter is defined as float value in seconds. Dem configuration tools must convert this float value to the appropriate value format for the use in the software implementation of Dem. Exactly one DemTaskTime must be specified per configuration. * min: A negative value is not allowed. * max: After event status was reported, processing shall be completed within 100ms in order to have the fault entry status information updated as soon as possible (e.g. for PID $01). 41fcb68aea61e999b1de905d889972c9d217ecaf 879 878 2014-08-01T08:37:33Z Oliver 1 /* Containers and configuration parameters */ wikitext text/x-wiki The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the [[diagnostic event]]s detected by [[diagnostic monitor]]s in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus === [[Container]]s and configuration parameters === Format: ''Container / Parameter {Multiplicity; Type; ConfigurationClass; Range}'' ''Description'' ==== DemConfigSet ==== Multiplicity:=1 ==== DemGeneral ==== Multiplicity:=1 DemGeneral/'''DemAgingCycleCounterProcessing''' {1; [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the aging counter is calculated Dem-internally or provided via [[Dem_SetAgingCycleCounterValue]]. * DEM_PROCESS_AGINGCTR_EXTERN: based on [[API]] [[Dem_SetAgingCycleCounterValue]] * DEM_PROCESS_AGINGCTR_INTERN: based on reported cycle states DemGeneral/'''DemBswErrorBufferSize''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of elements in buffer for handling of BSW errors. DemGeneral/'''DemClearDTCBehavior''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} Defines the clearing process of diagnostic information for volatile and [[non-volatile memory]] and the positive response handling for the [[Dcm]] module. * DEM_CLRRESP_NONVOLATILE_FINISH: Return DEM_CLEAR_OK after volatile and non-volatile event memory data cleared. * DEM_CLRRESP_NONVOLATILE_TRIGGER: Return DEM_CLEAR_OK after volatile event memory data cleared and non-volatile event memory clearing is triggered * DEM_CLRRESP_VOLATILE: Return DEM_CLEAR_OK after volatile event memory data cleared DemGeneral/'''DemDTCSuppressionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for [[DTC]] suppression is enabled or not. * TRUE: DTC suppression support is enabled * FALSE: DTC suppression support is disabled DemGeneral/'''DemDebounceCounterBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for counter based debouncing is enabled or not. * TRUE: counter based debouncing support is enabled * FALSE: counter based debouncing support is disabled DemGeneral/'''DemDebounceTimeBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for time based debouncing is enabled or not. * TRUE: time based debouncing support is enabled * FALSE: time based debouncing support is disabled DemGeneral/'''DemDevErrorDetect''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the Development Error Detection and Notification. * TRUE: Development Error Detection and Notification activated * FALSE: DevelopmentError Detection and Notification deactivated DemGeneral/'''DemDtcStatusAvailabilityMask''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Mask for the supported [[DTC]] status bits by the Dem. This mask is used by [[UDS]] service 0x19. DemGeneral/'''DemEnableConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for enable conditions is enabled or not. * TRUE: support for enable conditions is enabled * FALSE: support for enable conditions is disabled DemGeneral/'''DemEventCombinationSupport''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of event combination supported by the Dem. * DEM_EVCOMB_DISABLED: No event combination supported * DEM_EVCOMB_TYPE1: Event combination Type 1 enabled * DEM_EVCOMB_TYPE2: Event combination Type 2 enabled DemGeneral/'''DemEventDisplacementSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for event displacement is enabled or not. * TRUE: event displacement support is enabled * FALSE: event displacement support is disabled DemGeneral/'''DemExtendedDataCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the extended data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of extended data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of extended data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemFreezeFrameCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the freeze frame data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of freeze frame data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of freeze frame data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemHeaderFileInclusion''' {0..*, [[EcucStringParamDef|String]]; [[Pre-compile time|Pre]]} Name of the header file(s) to be included by the Dem module containing the used C-[[callback]] declarations. DemGeneral/'''DemImmediateNvStorageLimit''' {0..1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} This parameter defines the maximum number of occurrences, a specific event memory entry is allowed, to be stored in [[NVRAM]] immediately (refer to [[DemImmediateNvStorage]]). DemGeneral/'''DemMaxNumberEventEntryMirror''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[mirror memory]]. DemGeneral/'''DemMaxNumberEventEntryPermanent''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[permanent memory]]. The assignment of an event to this memory type is dynamic and used for emission-related events only. DemGeneral/'''DemMaxNumberEventEntryPrimary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} Maximum number of events which can be stored in the [[primary memory]]. DemGeneral/'''DemMaxNumberEventEntrySecondary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[secondary memory]]. DemGeneral/'''DemMaxNumberPrestoredFF''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Defines the maximum number for pre-stored [[freeze frame]]s. If set to 0, then freeze frame pre-storage is not supported by the [[ECU]]. DemGeneral/'''DemOBDSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines whether [[OBD]] is supported or not. DemGeneral/'''DemOccurrenceCounterProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines the consideration of the fault confirmation process for the occurrence counter. For [[OBD]] and mixed systems (OBD/non OBD, refer to [[DemOBDSupport]]) the fault confirmation process must not be considered. * DEM_PROCESS_OCCCTR_CDTC: the occurrence counter is triggered by the TestFailed bit only, but the fault confirmation is not considered * DEM_PROCESS_OCCCTR_TF: the occurrence counter is triggered after the fault confirmation was successful DemGeneral/'''DemOperationCycleProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[operation cycle]]s are triggered by DEM_CYCLE_STATE_START or collecting an external counter value, which results in respective state changes. * DEM_PROCESS_OPCYC_COUNTER: operation cycle processing is based on [[API]] [[Dem_SetOperationCycleCntValue]] * DEM_PROCESS_OPCYC_STATE: operation cycle processing is based on API [[Dem_SetOperationCycleState]] DemGeneral/'''DemOperationCycleStatusStorage''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the operation cycle state is available over the [[power cycle]] (stored non-volatile) or not. * TRUE: the operation cycle state is stored [[non-volatile]] * FALSE: the operation cycle state is only stored [[volatile]] DemGeneral/'''DemPTOSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether [[PTO]] support (and therefore [[PID]] $1E support) is enabled or not. DemGeneral/'''DemStatusBitHandlingTestFailedSinceLastClear''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[aging]] and displacement mechanism shall be applied to the "[[TestFailedSinceLastClear]]" status bits. * DEM_STATUS_BIT_AGING_AND_DISPLACEMENT: the "TestFailedSinceLastClear" status bits are reset to 0, if aging or displacement applies (like done for the "[[ConfirmedDTC]]" status bits) * DEM_STATUS_BIT_NORMAL: aging and displacement has no impact on the "TestFailedSinceLastClear" status bits DemGeneral/'''DemStatusBitStorageTestFailed''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the permanent storage of the "[[TestFailed]]" status bits. * TRUE: storage activated * FALSE: storage deactivated DemGeneral/'''DemStorageConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for storage conditions is enabled or not. * TRUE: support for storage conditions is enabled * FALSE: support for storage conditions is disabled DemGeneral/'''DemTaskTime''' {1, [[EcucFloatParamDef|Float]]; [[Pre-compile time|Pre]]; 0..0.1} Allow to configure the time for the periodic [[cyclic task]]. Please note: This configuration value shall be equal to the value in the [[Basic Software Scheduler]] configuration of the [[RTE]] module. The AUTOSAR configuration standard is to use [[SI unit]]s, so this parameter is defined as float value in seconds. Dem configuration tools must convert this float value to the appropriate value format for the use in the software implementation of Dem. Exactly one DemTaskTime must be specified per configuration. * min: A negative value is not allowed. * max: After event status was reported, processing shall be completed within 100ms in order to have the fault entry status information updated as soon as possible (e.g. for PID $01). DemGeneral/'''DemTriggerDcmReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Diagnostic Communication Manager]] for [[ROE processing]]. * TRUE: Dcm ROE notification activated * FALSE: Dcm ROE notification deactivated DemGeneral/'''DemTriggerDltReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Diagnostic Log and Trace]]. * TRUE: Dlt notification activated * FALSE: Dlt notification deactivated DemGeneral/'''DemTriggerFiMReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Funciton Inhibition Manager]]. * TRUE: FiM notification activated * FALSE: FiM notification deactivated DemGeneral/'''DemTriggerMonitorInitBeforeClearOk''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the monitor re-initialization has to be triggered before or after the Dem module returns DEM_CLEAR_OK. * TRUE: trigger re-initialization before DEM_CLEAR_OK * FALSE: trigger re-initialization after DEM_CLEAR_OK DemGeneral/'''DemTypeOfDTCSupported''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the format returned by [[Dem_GetTranslationType]] and does not relate to/influence the supported Dem functionality. * DEM_DTC_TRANSLATION_ISO11992_4: [[ISO11992-4]] DTC format * DEM_DTC_TRANSLATION_ISO14229_1: [[ISO14229-1]] DTC format (3 byte format) * DEM_DTC_TRANSLATION_ISO15031_6: [[ISO15031-6]] DTC format (2 byte format) * DEM_DTC_TRANSLATION_SAEJ1939_73: [[SAEJ1939-73]] DTC format DemGeneral/'''DemTypeOfFreezeFrameRecordNumeration''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of assigning [[freeze frame]] record numbers for event-specific freeze frame records. * DEM_FF_RECNUM_CALCULATED: freeze frame records will be numbered consecutive starting by 1 in their chronological order * DEM_FF_RECNUM_CONFIGURED: freeze frame records will be numbered based on the given configuration in their chronological order DemGeneral/'''DemVersionInfoApi''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the version information [[API]]. * TRUE: version information activated * FALSE: version information deactivated DemGeneral/'''DemMILIndicatorRef''' {0..1, [[DemIndicator|Reference]]; [[Pre-compile time|Pre]]} This parameter defines the indicator representing the [[MIL]]. This parameter is mandatory for [[ECU]]s supporting [[OBD]] (refer to [[DemOBDSupport]]). dcb9984ea9426aae3d4bb94cb8f2d2b3c38eb0ac 884 879 2014-08-04T13:09:26Z 192.168.2.119 0 /* Standardized Interface */ wikitext text/x-wiki The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the [[diagnostic event]]s detected by [[diagnostic monitor]]s in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === Dem_ReportErrorStatus Dem_GetVersionInfo === [[Container]]s and configuration parameters === Format: ''Container / Parameter {Multiplicity; Type; ConfigurationClass; Range}'' ''Description'' ==== DemConfigSet ==== Multiplicity:=1 ==== DemGeneral ==== Multiplicity:=1 DemGeneral/'''DemAgingCycleCounterProcessing''' {1; [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the aging counter is calculated Dem-internally or provided via [[Dem_SetAgingCycleCounterValue]]. * DEM_PROCESS_AGINGCTR_EXTERN: based on [[API]] [[Dem_SetAgingCycleCounterValue]] * DEM_PROCESS_AGINGCTR_INTERN: based on reported cycle states DemGeneral/'''DemBswErrorBufferSize''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of elements in buffer for handling of BSW errors. DemGeneral/'''DemClearDTCBehavior''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} Defines the clearing process of diagnostic information for volatile and [[non-volatile memory]] and the positive response handling for the [[Dcm]] module. * DEM_CLRRESP_NONVOLATILE_FINISH: Return DEM_CLEAR_OK after volatile and non-volatile event memory data cleared. * DEM_CLRRESP_NONVOLATILE_TRIGGER: Return DEM_CLEAR_OK after volatile event memory data cleared and non-volatile event memory clearing is triggered * DEM_CLRRESP_VOLATILE: Return DEM_CLEAR_OK after volatile event memory data cleared DemGeneral/'''DemDTCSuppressionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for [[DTC]] suppression is enabled or not. * TRUE: DTC suppression support is enabled * FALSE: DTC suppression support is disabled DemGeneral/'''DemDebounceCounterBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for counter based debouncing is enabled or not. * TRUE: counter based debouncing support is enabled * FALSE: counter based debouncing support is disabled DemGeneral/'''DemDebounceTimeBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for time based debouncing is enabled or not. * TRUE: time based debouncing support is enabled * FALSE: time based debouncing support is disabled DemGeneral/'''DemDevErrorDetect''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the Development Error Detection and Notification. * TRUE: Development Error Detection and Notification activated * FALSE: DevelopmentError Detection and Notification deactivated DemGeneral/'''DemDtcStatusAvailabilityMask''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Mask for the supported [[DTC]] status bits by the Dem. This mask is used by [[UDS]] service 0x19. DemGeneral/'''DemEnableConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for enable conditions is enabled or not. * TRUE: support for enable conditions is enabled * FALSE: support for enable conditions is disabled DemGeneral/'''DemEventCombinationSupport''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of event combination supported by the Dem. * DEM_EVCOMB_DISABLED: No event combination supported * DEM_EVCOMB_TYPE1: Event combination Type 1 enabled * DEM_EVCOMB_TYPE2: Event combination Type 2 enabled DemGeneral/'''DemEventDisplacementSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for event displacement is enabled or not. * TRUE: event displacement support is enabled * FALSE: event displacement support is disabled DemGeneral/'''DemExtendedDataCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the extended data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of extended data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of extended data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemFreezeFrameCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the freeze frame data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of freeze frame data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of freeze frame data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemHeaderFileInclusion''' {0..*, [[EcucStringParamDef|String]]; [[Pre-compile time|Pre]]} Name of the header file(s) to be included by the Dem module containing the used C-[[callback]] declarations. DemGeneral/'''DemImmediateNvStorageLimit''' {0..1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} This parameter defines the maximum number of occurrences, a specific event memory entry is allowed, to be stored in [[NVRAM]] immediately (refer to [[DemImmediateNvStorage]]). DemGeneral/'''DemMaxNumberEventEntryMirror''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[mirror memory]]. DemGeneral/'''DemMaxNumberEventEntryPermanent''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[permanent memory]]. The assignment of an event to this memory type is dynamic and used for emission-related events only. DemGeneral/'''DemMaxNumberEventEntryPrimary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} Maximum number of events which can be stored in the [[primary memory]]. DemGeneral/'''DemMaxNumberEventEntrySecondary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[secondary memory]]. DemGeneral/'''DemMaxNumberPrestoredFF''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Defines the maximum number for pre-stored [[freeze frame]]s. If set to 0, then freeze frame pre-storage is not supported by the [[ECU]]. DemGeneral/'''DemOBDSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines whether [[OBD]] is supported or not. DemGeneral/'''DemOccurrenceCounterProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines the consideration of the fault confirmation process for the occurrence counter. For [[OBD]] and mixed systems (OBD/non OBD, refer to [[DemOBDSupport]]) the fault confirmation process must not be considered. * DEM_PROCESS_OCCCTR_CDTC: the occurrence counter is triggered by the TestFailed bit only, but the fault confirmation is not considered * DEM_PROCESS_OCCCTR_TF: the occurrence counter is triggered after the fault confirmation was successful DemGeneral/'''DemOperationCycleProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[operation cycle]]s are triggered by DEM_CYCLE_STATE_START or collecting an external counter value, which results in respective state changes. * DEM_PROCESS_OPCYC_COUNTER: operation cycle processing is based on [[API]] [[Dem_SetOperationCycleCntValue]] * DEM_PROCESS_OPCYC_STATE: operation cycle processing is based on API [[Dem_SetOperationCycleState]] DemGeneral/'''DemOperationCycleStatusStorage''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the operation cycle state is available over the [[power cycle]] (stored non-volatile) or not. * TRUE: the operation cycle state is stored [[non-volatile]] * FALSE: the operation cycle state is only stored [[volatile]] DemGeneral/'''DemPTOSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether [[PTO]] support (and therefore [[PID]] $1E support) is enabled or not. DemGeneral/'''DemStatusBitHandlingTestFailedSinceLastClear''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[aging]] and displacement mechanism shall be applied to the "[[TestFailedSinceLastClear]]" status bits. * DEM_STATUS_BIT_AGING_AND_DISPLACEMENT: the "TestFailedSinceLastClear" status bits are reset to 0, if aging or displacement applies (like done for the "[[ConfirmedDTC]]" status bits) * DEM_STATUS_BIT_NORMAL: aging and displacement has no impact on the "TestFailedSinceLastClear" status bits DemGeneral/'''DemStatusBitStorageTestFailed''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the permanent storage of the "[[TestFailed]]" status bits. * TRUE: storage activated * FALSE: storage deactivated DemGeneral/'''DemStorageConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for storage conditions is enabled or not. * TRUE: support for storage conditions is enabled * FALSE: support for storage conditions is disabled DemGeneral/'''DemTaskTime''' {1, [[EcucFloatParamDef|Float]]; [[Pre-compile time|Pre]]; 0..0.1} Allow to configure the time for the periodic [[cyclic task]]. Please note: This configuration value shall be equal to the value in the [[Basic Software Scheduler]] configuration of the [[RTE]] module. The AUTOSAR configuration standard is to use [[SI unit]]s, so this parameter is defined as float value in seconds. Dem configuration tools must convert this float value to the appropriate value format for the use in the software implementation of Dem. Exactly one DemTaskTime must be specified per configuration. * min: A negative value is not allowed. * max: After event status was reported, processing shall be completed within 100ms in order to have the fault entry status information updated as soon as possible (e.g. for PID $01). DemGeneral/'''DemTriggerDcmReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Diagnostic Communication Manager]] for [[ROE processing]]. * TRUE: Dcm ROE notification activated * FALSE: Dcm ROE notification deactivated DemGeneral/'''DemTriggerDltReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Diagnostic Log and Trace]]. * TRUE: Dlt notification activated * FALSE: Dlt notification deactivated DemGeneral/'''DemTriggerFiMReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Funciton Inhibition Manager]]. * TRUE: FiM notification activated * FALSE: FiM notification deactivated DemGeneral/'''DemTriggerMonitorInitBeforeClearOk''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the monitor re-initialization has to be triggered before or after the Dem module returns DEM_CLEAR_OK. * TRUE: trigger re-initialization before DEM_CLEAR_OK * FALSE: trigger re-initialization after DEM_CLEAR_OK DemGeneral/'''DemTypeOfDTCSupported''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the format returned by [[Dem_GetTranslationType]] and does not relate to/influence the supported Dem functionality. * DEM_DTC_TRANSLATION_ISO11992_4: [[ISO11992-4]] DTC format * DEM_DTC_TRANSLATION_ISO14229_1: [[ISO14229-1]] DTC format (3 byte format) * DEM_DTC_TRANSLATION_ISO15031_6: [[ISO15031-6]] DTC format (2 byte format) * DEM_DTC_TRANSLATION_SAEJ1939_73: [[SAEJ1939-73]] DTC format DemGeneral/'''DemTypeOfFreezeFrameRecordNumeration''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of assigning [[freeze frame]] record numbers for event-specific freeze frame records. * DEM_FF_RECNUM_CALCULATED: freeze frame records will be numbered consecutive starting by 1 in their chronological order * DEM_FF_RECNUM_CONFIGURED: freeze frame records will be numbered based on the given configuration in their chronological order DemGeneral/'''DemVersionInfoApi''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the version information [[API]]. * TRUE: version information activated * FALSE: version information deactivated DemGeneral/'''DemMILIndicatorRef''' {0..1, [[DemIndicator|Reference]]; [[Pre-compile time|Pre]]} This parameter defines the indicator representing the [[MIL]]. This parameter is mandatory for [[ECU]]s supporting [[OBD]] (refer to [[DemOBDSupport]]). d1a2388e7bb5727736d334f8a994c1534ea45f3a 885 884 2014-08-04T13:09:44Z 192.168.2.119 0 /* Standardized Interface */ wikitext text/x-wiki The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the [[diagnostic event]]s detected by [[diagnostic monitor]]s in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === * Dem_ReportErrorStatus * Dem_GetVersionInfo === [[Container]]s and configuration parameters === Format: ''Container / Parameter {Multiplicity; Type; ConfigurationClass; Range}'' ''Description'' ==== DemConfigSet ==== Multiplicity:=1 ==== DemGeneral ==== Multiplicity:=1 DemGeneral/'''DemAgingCycleCounterProcessing''' {1; [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the aging counter is calculated Dem-internally or provided via [[Dem_SetAgingCycleCounterValue]]. * DEM_PROCESS_AGINGCTR_EXTERN: based on [[API]] [[Dem_SetAgingCycleCounterValue]] * DEM_PROCESS_AGINGCTR_INTERN: based on reported cycle states DemGeneral/'''DemBswErrorBufferSize''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of elements in buffer for handling of BSW errors. DemGeneral/'''DemClearDTCBehavior''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} Defines the clearing process of diagnostic information for volatile and [[non-volatile memory]] and the positive response handling for the [[Dcm]] module. * DEM_CLRRESP_NONVOLATILE_FINISH: Return DEM_CLEAR_OK after volatile and non-volatile event memory data cleared. * DEM_CLRRESP_NONVOLATILE_TRIGGER: Return DEM_CLEAR_OK after volatile event memory data cleared and non-volatile event memory clearing is triggered * DEM_CLRRESP_VOLATILE: Return DEM_CLEAR_OK after volatile event memory data cleared DemGeneral/'''DemDTCSuppressionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for [[DTC]] suppression is enabled or not. * TRUE: DTC suppression support is enabled * FALSE: DTC suppression support is disabled DemGeneral/'''DemDebounceCounterBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for counter based debouncing is enabled or not. * TRUE: counter based debouncing support is enabled * FALSE: counter based debouncing support is disabled DemGeneral/'''DemDebounceTimeBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for time based debouncing is enabled or not. * TRUE: time based debouncing support is enabled * FALSE: time based debouncing support is disabled DemGeneral/'''DemDevErrorDetect''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the Development Error Detection and Notification. * TRUE: Development Error Detection and Notification activated * FALSE: DevelopmentError Detection and Notification deactivated DemGeneral/'''DemDtcStatusAvailabilityMask''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Mask for the supported [[DTC]] status bits by the Dem. This mask is used by [[UDS]] service 0x19. DemGeneral/'''DemEnableConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for enable conditions is enabled or not. * TRUE: support for enable conditions is enabled * FALSE: support for enable conditions is disabled DemGeneral/'''DemEventCombinationSupport''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of event combination supported by the Dem. * DEM_EVCOMB_DISABLED: No event combination supported * DEM_EVCOMB_TYPE1: Event combination Type 1 enabled * DEM_EVCOMB_TYPE2: Event combination Type 2 enabled DemGeneral/'''DemEventDisplacementSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for event displacement is enabled or not. * TRUE: event displacement support is enabled * FALSE: event displacement support is disabled DemGeneral/'''DemExtendedDataCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the extended data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of extended data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of extended data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemFreezeFrameCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the freeze frame data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of freeze frame data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of freeze frame data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemHeaderFileInclusion''' {0..*, [[EcucStringParamDef|String]]; [[Pre-compile time|Pre]]} Name of the header file(s) to be included by the Dem module containing the used C-[[callback]] declarations. DemGeneral/'''DemImmediateNvStorageLimit''' {0..1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} This parameter defines the maximum number of occurrences, a specific event memory entry is allowed, to be stored in [[NVRAM]] immediately (refer to [[DemImmediateNvStorage]]). DemGeneral/'''DemMaxNumberEventEntryMirror''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[mirror memory]]. DemGeneral/'''DemMaxNumberEventEntryPermanent''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[permanent memory]]. The assignment of an event to this memory type is dynamic and used for emission-related events only. DemGeneral/'''DemMaxNumberEventEntryPrimary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} Maximum number of events which can be stored in the [[primary memory]]. DemGeneral/'''DemMaxNumberEventEntrySecondary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[secondary memory]]. DemGeneral/'''DemMaxNumberPrestoredFF''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Defines the maximum number for pre-stored [[freeze frame]]s. If set to 0, then freeze frame pre-storage is not supported by the [[ECU]]. DemGeneral/'''DemOBDSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines whether [[OBD]] is supported or not. DemGeneral/'''DemOccurrenceCounterProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines the consideration of the fault confirmation process for the occurrence counter. For [[OBD]] and mixed systems (OBD/non OBD, refer to [[DemOBDSupport]]) the fault confirmation process must not be considered. * DEM_PROCESS_OCCCTR_CDTC: the occurrence counter is triggered by the TestFailed bit only, but the fault confirmation is not considered * DEM_PROCESS_OCCCTR_TF: the occurrence counter is triggered after the fault confirmation was successful DemGeneral/'''DemOperationCycleProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[operation cycle]]s are triggered by DEM_CYCLE_STATE_START or collecting an external counter value, which results in respective state changes. * DEM_PROCESS_OPCYC_COUNTER: operation cycle processing is based on [[API]] [[Dem_SetOperationCycleCntValue]] * DEM_PROCESS_OPCYC_STATE: operation cycle processing is based on API [[Dem_SetOperationCycleState]] DemGeneral/'''DemOperationCycleStatusStorage''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the operation cycle state is available over the [[power cycle]] (stored non-volatile) or not. * TRUE: the operation cycle state is stored [[non-volatile]] * FALSE: the operation cycle state is only stored [[volatile]] DemGeneral/'''DemPTOSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether [[PTO]] support (and therefore [[PID]] $1E support) is enabled or not. DemGeneral/'''DemStatusBitHandlingTestFailedSinceLastClear''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[aging]] and displacement mechanism shall be applied to the "[[TestFailedSinceLastClear]]" status bits. * DEM_STATUS_BIT_AGING_AND_DISPLACEMENT: the "TestFailedSinceLastClear" status bits are reset to 0, if aging or displacement applies (like done for the "[[ConfirmedDTC]]" status bits) * DEM_STATUS_BIT_NORMAL: aging and displacement has no impact on the "TestFailedSinceLastClear" status bits DemGeneral/'''DemStatusBitStorageTestFailed''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the permanent storage of the "[[TestFailed]]" status bits. * TRUE: storage activated * FALSE: storage deactivated DemGeneral/'''DemStorageConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for storage conditions is enabled or not. * TRUE: support for storage conditions is enabled * FALSE: support for storage conditions is disabled DemGeneral/'''DemTaskTime''' {1, [[EcucFloatParamDef|Float]]; [[Pre-compile time|Pre]]; 0..0.1} Allow to configure the time for the periodic [[cyclic task]]. Please note: This configuration value shall be equal to the value in the [[Basic Software Scheduler]] configuration of the [[RTE]] module. The AUTOSAR configuration standard is to use [[SI unit]]s, so this parameter is defined as float value in seconds. Dem configuration tools must convert this float value to the appropriate value format for the use in the software implementation of Dem. Exactly one DemTaskTime must be specified per configuration. * min: A negative value is not allowed. * max: After event status was reported, processing shall be completed within 100ms in order to have the fault entry status information updated as soon as possible (e.g. for PID $01). DemGeneral/'''DemTriggerDcmReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Diagnostic Communication Manager]] for [[ROE processing]]. * TRUE: Dcm ROE notification activated * FALSE: Dcm ROE notification deactivated DemGeneral/'''DemTriggerDltReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Diagnostic Log and Trace]]. * TRUE: Dlt notification activated * FALSE: Dlt notification deactivated DemGeneral/'''DemTriggerFiMReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Funciton Inhibition Manager]]. * TRUE: FiM notification activated * FALSE: FiM notification deactivated DemGeneral/'''DemTriggerMonitorInitBeforeClearOk''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the monitor re-initialization has to be triggered before or after the Dem module returns DEM_CLEAR_OK. * TRUE: trigger re-initialization before DEM_CLEAR_OK * FALSE: trigger re-initialization after DEM_CLEAR_OK DemGeneral/'''DemTypeOfDTCSupported''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the format returned by [[Dem_GetTranslationType]] and does not relate to/influence the supported Dem functionality. * DEM_DTC_TRANSLATION_ISO11992_4: [[ISO11992-4]] DTC format * DEM_DTC_TRANSLATION_ISO14229_1: [[ISO14229-1]] DTC format (3 byte format) * DEM_DTC_TRANSLATION_ISO15031_6: [[ISO15031-6]] DTC format (2 byte format) * DEM_DTC_TRANSLATION_SAEJ1939_73: [[SAEJ1939-73]] DTC format DemGeneral/'''DemTypeOfFreezeFrameRecordNumeration''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of assigning [[freeze frame]] record numbers for event-specific freeze frame records. * DEM_FF_RECNUM_CALCULATED: freeze frame records will be numbered consecutive starting by 1 in their chronological order * DEM_FF_RECNUM_CONFIGURED: freeze frame records will be numbered based on the given configuration in their chronological order DemGeneral/'''DemVersionInfoApi''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the version information [[API]]. * TRUE: version information activated * FALSE: version information deactivated DemGeneral/'''DemMILIndicatorRef''' {0..1, [[DemIndicator|Reference]]; [[Pre-compile time|Pre]]} This parameter defines the indicator representing the [[MIL]]. This parameter is mandatory for [[ECU]]s supporting [[OBD]] (refer to [[DemOBDSupport]]). bc2be54d4175a0d19020d827066dd02cac7c362f 0 600 872 2014-07-30T20:38:06Z 192.168.2.119 0 Redirected page to [[Basic Software Module]] wikitext text/x-wiki #REDIRECT [[Basic Software Module]] 3eccfbf678b725223674b8453073f6e2c449d456 0 601 873 2014-07-30T20:44:49Z 192.168.2.119 0 Redirected page to [[Diagnostic Event Manager]] wikitext text/x-wiki #REDIRECT [[Diagnostic Event Manager]] 728981ed3a8598e339050023e2a104573111945d 0 602 874 2014-07-30T20:45:07Z 192.168.2.119 0 Created page with "A ´Diagnostic Event´ (identified by an [[EventId]] as a symbolic [[EventName]]) defines the atomic unit that can be handled by the [[Dem]] module. The status of a ´Diagnost..." wikitext text/x-wiki A ´Diagnostic Event´ (identified by an [[EventId]] as a symbolic [[EventName]]) defines the atomic unit that can be handled by the [[Dem]] module. The status of a ´Diagnostic Event´ represents the result of a [[diagnostic monitor]]. The Dem receives the result of a monitor from [[SW-C]] via the [[RTE]] or other [[BSW module]]s. d24b305425241744e643892d74f1d8a3227bc23d 0 603 880 2014-08-04T09:28:09Z Oliver 1 Created page with "A diagnostic monitor is a routine entity determining the proper functionality of a component. Alternatively the term “diagnostic function” can be used." wikitext text/x-wiki A diagnostic monitor is a routine entity determining the proper functionality of a component. Alternatively the term “diagnostic function” can be used. deaf124c07fd3fec6f1eb49708368d22b2f053ba 902 880 2014-08-06T20:38:14Z 192.168.2.119 0 wikitext text/x-wiki A diagnostic monitor is a routine entity determining the proper functionality of a component by identifying a specific fault type (e.g. short to ground, open load, etc.) for a [[monitoring path]]. Alternatively the term “diagnostic function” can be used. bf1bb62cfe71273f782d9d1d22da9dd67b244cfb 0 604 881 2014-08-04T09:43:55Z Oliver 1 Redirected page to [[Diagnostic monitor]] wikitext text/x-wiki #REDIRECT [[diagnostic monitor]] d945d199f8fb5ee923464dc926a535c4c88759b5 0 587 882 853 2014-08-04T11:56:02Z 192.168.2.119 0 wikitext text/x-wiki Unlearning/deleting of a no longer failed event/[[DTC]] after a defined number of [[operation cycle]]s from [[event memory]]. The [[Dem]] module provides the ability to remove a specific event from the event memory, if its fault conditions are not fulfilled for a certain period of time (operation cycles). This process is called as “aging” or “unlearning”. 32fc2be4075005223fa9a2bd46cba99bc0ec1e1f 0 605 883 2014-08-04T11:56:15Z 192.168.2.119 0 Redirected page to [[Aging]] wikitext text/x-wiki #REDIRECT [[Aging]] 6fd81dd469dc97baccd36ce3affec3a62d480760 0 606 886 2014-08-05T06:19:23Z 192.168.2.119 0 Redirected page to [[Production Part Approval Process]] wikitext text/x-wiki #REDIRECT [[Production Part Approval Process]] 422e6209857ab1264bcbaee6ba709cd6244962ba 0 607 887 2014-08-05T06:22:53Z 192.168.2.119 0 Created page with "Das Produktionsteil-Freigabeverfahren (Production Part Approval Process) ist ein Bemusterungsverfahren für Hardware(komponenten) im Automobilbereich. Parallel dazu gibt es no..." wikitext text/x-wiki Das Produktionsteil-Freigabeverfahren (Production Part Approval Process) ist ein Bemusterungsverfahren für Hardware(komponenten) im Automobilbereich. Parallel dazu gibt es noch das Produktionsprozess- und Produktfreigabe Verfahren (PPF-Verfahren). 4f717577ce5c4fb261a88446354db236d2da7527 888 887 2014-08-05T06:24:21Z 192.168.2.119 0 wikitext text/x-wiki Das Produktionsteil-Freigabeverfahren (Production Part Approval Process) [http://www.qualitaetsmanagement.me/PPAP.htm] ist ein Bemusterungsverfahren für Hardware(komponenten) im Automobilbereich. Parallel dazu gibt es noch das Produktionsprozess- und Produktfreigabe Verfahren (PPF-Verfahren). 58742e9ea80aa23f75de84355042c37dd10ae1a1 0 608 889 2014-08-05T06:25:48Z 192.168.2.119 0 Redirected page to [[Automotive Electronics Council]] wikitext text/x-wiki #REDIRECT [[Automotive Electronics Council]] 4d2a6e4ae4a0a53df5bcfab0eb0aa1650c771166 0 609 890 2014-08-05T06:26:28Z 192.168.2.119 0 Created page with "siehe Wikipedia [https://de.wikipedia.org/wiki/Automotive_Electronics_Council]" wikitext text/x-wiki siehe Wikipedia [https://de.wikipedia.org/wiki/Automotive_Electronics_Council] fc93bd73422d665982a20cd3a5bb84ab6009841d 0 610 891 2014-08-05T06:26:58Z 192.168.2.119 0 Redirected page to [[Automotive Electronics Council]] wikitext text/x-wiki #REDIRECT [[Automotive Electronics Council]] 4d2a6e4ae4a0a53df5bcfab0eb0aa1650c771166 0 611 892 2014-08-05T11:18:26Z 192.168.2.119 0 Created page with "Automotive suppliers are called Tier with the corresponding number according to their position in supplier chain. The supplier chain therefore looks like: Vehicle manufacture..." wikitext text/x-wiki Automotive suppliers are called Tier with the corresponding number according to their position in supplier chain. The supplier chain therefore looks like: Vehicle manufacturer ([[OEM]]) <= Tier1 <= Tier2 <= etc. 6ada5c891324963b31ad37a786f0d9c402cc5fc3 0 612 893 2014-08-06T06:35:37Z 192.168.2.119 0 Redirected page to [[Types and prototypes]] wikitext text/x-wiki #REDIRECT [[Types and prototypes]] 9765cc148d2fcd0330649472f5f39c0aa246a783 0 613 894 2014-08-06T06:35:51Z 192.168.2.119 0 Redirected page to [[Types and prototypes]] wikitext text/x-wiki #REDIRECT [[Types and prototypes]] 9765cc148d2fcd0330649472f5f39c0aa246a783 0 614 895 2014-08-06T06:36:07Z 192.168.2.119 0 Created page with "AUTOSAR defines types and prototypes. This concept allows re-using elements (like [[SW-C]]) several times. E.g. a SW-C type defines the properties of the SW-C together with th..." wikitext text/x-wiki AUTOSAR defines types and prototypes. This concept allows re-using elements (like [[SW-C]]) several times. E.g. a SW-C type defines the properties of the SW-C together with the [[port]]s, [[internal behavior]] etc. The SW-C prototype is the usage of a SW-C type. The prototype contains all elements and properties of the type plus additional properties such as the shortName. In analogy to C++ the type would be the class and the prototype the instantiation of this class. 95d653d964ae0f95fb8fc0f57b1abc377a7f7498 0 275 896 560 2014-08-06T12:38:14Z 192.168.2.119 0 wikitext text/x-wiki A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[Provide Port]] (p-port, PPort) or a [[Require Port]] (r-port, RPort). A port of a SW-C is associated with a [[port-interface]]. The occurrence of an unconnected port is not per se a design mistake. It can be valid when an application provider for the [[data element]] is absent and the default init value is good enough to operate with or it could be that an end point was removed from the [[system]] because it is subjected to variability (See [[Variant Handling]]). Ports are the interconnection points between [[software component]]s. Ports of different SWC can be connected to indicate a data flow between them. The details, i.e. the kind of information that is actually transported between the ports, are defined by [[port-interface]]s. [SystemDesk tutorial] == Unconnected Sender Ports == Data of the sender will not appear on VFB. Generated RTE might simply call empty function or even optimize function call to zero code. == Unconnected Synchronous Receiver Ports == The RPort will always read the initial value specified for this RPort. == Unconnected Asynchronous Receiver Ports == The RPort will receive a time-out like the Sender is not providing data. == Unconnected Server Ports == The operations (functions) of the PPort interface will never be called. Generated RTE (or finally the compiler) might even optimize operation to zero code. == Unconnected Client Ports == According to AUTOSAR specification the [[operation]]s (functions) on the RPort will TIME_OUT. But more likely the [[RTE-Generator]] will generate a return code RTE_E_UNCONNECTED for any unconnected [[client]] interface operation. f309e3aa1d0897d715eb1484158771691336b6ce 0 144 897 465 2014-08-06T12:44:51Z 192.168.2.119 0 wikitext text/x-wiki A connector symbolizes the data flow from one [[PPort]] to one [[RPort]] of [[Software Component]]s (SW-C) or [[Software composition]]s. There are two types of connectors = Assembly Connector = Assembly connectors connect ports of SW-C. = Delegation Connector = Delegation connectors connect the Software Composition with its inner Software Components. During the design of an [[AUTOSAR system]], ports between Software Components that need to communicate with each other are hooked up using [[Assembly Connector]]s. Such an Assembly Connector connects one 326fba202bb4ad6d5f186fd223c5d73fdf4a868f 900 897 2014-08-06T12:46:49Z 192.168.2.119 0 /* Delegation Connector */ wikitext text/x-wiki A connector symbolizes the data flow from one [[PPort]] to one [[RPort]] of [[Software Component]]s (SW-C) or [[Software composition]]s. There are two types of connectors = Assembly Connector = Assembly connectors connect ports of SW-C. = Delegation Connector = Delegation connectors connect the Software Composition with its inner Software Components. During the design of an [[AUTOSAR system]], ports between Software Components that need to communicate with each other are hooked up using Assembly Connectors. Such an Assembly Connector connects one 169f21eb8e0d6e5c898aa3325859d5e9bda8c782 0 616 899 2014-08-06T12:46:32Z 192.168.2.119 0 Redirected page to [[Connector#Delegation Connector]] wikitext text/x-wiki #REDIRECT [[Connector#Delegation Connector]] 6c0e782df13e59e1cf866f37de32543ce3184a47 0 617 901 2014-08-06T20:34:33Z 192.168.2.119 0 Created page with "A monitoring path represents the physical system or a circuit, that is being monitored (e.g. sensor input). Each monitoring path is associated to exactly one diagnostic even..." wikitext text/x-wiki A monitoring path represents the physical system or a circuit, that is being monitored (e.g. sensor input). Each monitoring path is associated to exactly one [[diagnostic event]]. 3d480d69988ee3283a42940a68b71c74ae521dce 0 618 903 2014-08-08T06:19:29Z 192.168.2.119 0 Created page with "During the development process there are several integration steps (Integrationsstufen, I-Stufen) planned by the [[OEM]] where the suppliers provide Software-Updates to be int..." wikitext text/x-wiki During the development process there are several integration steps (Integrationsstufen, I-Stufen) planned by the [[OEM]] where the suppliers provide Software-Updates to be integrated and tested into the vehicle. f4b7d3aa1de2f64724f40fe71e4e637f83873dba 0 619 904 2014-08-08T06:19:46Z 192.168.2.119 0 Redirected page to [[Integrationsstufe]] wikitext text/x-wiki #REDIRECT [[Integrationsstufe]] 364e4fe274688c424364c30910ce231242280d78 0 620 905 2014-08-08T06:19:58Z 192.168.2.119 0 Redirected page to [[Integrationsstufe]] wikitext text/x-wiki #REDIRECT [[Integrationsstufe]] 364e4fe274688c424364c30910ce231242280d78 0 104 906 475 2014-08-08T06:21:48Z 192.168.2.119 0 wikitext text/x-wiki An Application Software Component is a specific [[Software Component]] which realizes a defined functionality on application level (above the [[RTE]]) and runs on the AUTOSAR infrastructure. It communicates only through the AUTOSAR Runtime Environment (RTE). The Application Software Component is an [[Atomic Software Component]] that [[implement]]s (part of) an [[application]]. It can use all [[AUTOSAR communication mechanism]]s and [[service]]s. It interacts with [[sensor]]s or [[actuator]]s through a [[Sensor-Actuator Software Component]]. The Application Software Component is an [[Atomic Software Component]] that is hardware independent. 17c0132ada916edb44d88da385db8972ad8379f7 0 111 907 116 2014-08-08T06:23:56Z 192.168.2.119 0 wikitext text/x-wiki Non-composed Software-Component ([[SW-C]]). An Atomic Software Component might access [[HW]] or not, therefore not all Atomic SW-Cs are re-locatable. Any [Software Component]] that can contain a SW-C [[internal behavior]]. An Atomic Software Component communicates with the outside via the [[interface]]s at the SW-C [[port]]s. 59fb9c5a344564f5eeb73c9b45d9bdbd2e865d40 0 419 908 537 2014-08-08T08:06:41Z 192.168.2.119 0 wikitext text/x-wiki The Software Component Description (SWCD) defines all properties of a [[Software Component]] like [[port]]s, [[interface]]s, [[behavior]]. This could be done by [[ARtext]] language description, or with some Software Tool. Software Component Description is an [[XML]] file that describes a software architecture according to AUTOSAR. e965a8a50548806fb3d08b810dfc15e9c26084c8 0 621 909 2014-08-08T08:08:31Z 192.168.2.119 0 Redirected page to [[Port]] wikitext text/x-wiki #REDIRECT [[Port]] 8d7092ed22e5b9c0376c64229fba5a24fd4b3d85 0 622 910 2014-08-08T08:10:31Z 192.168.2.119 0 Created page with "A signal is transferred via the [[COM]] layer. COM signals can be used in [[intra-ECU]] and [[inter-ECU]] communication. In the latter case a COM signal contains parameters fo..." wikitext text/x-wiki A signal is transferred via the [[COM]] layer. COM signals can be used in [[intra-ECU]] and [[inter-ECU]] communication. In the latter case a COM signal contains parameters for [[network]] transmission. ea85b8e8b801259c42f7d9fe1803f6e8c034bd9e 0 135 911 146 2014-08-08T08:11:38Z 192.168.2.119 0 wikitext text/x-wiki A cluster signal represents the aggregating system signal on one specific [[communication cluster]]. Cluster signals can be defined independently of [[frame]]s. This allows a development [[methodology]] where the signals are defined first, and are assigned to frames in a later stage. 14a7f86327999ee87550dc0b2fc8f477ed0e141e 0 623 912 2014-08-08T08:14:28Z 192.168.2.119 0 Created page with "The Communication Cluster specifies the topological connection of communicating [[ECU]]s. In a communication cluster the ECUs are connected by one or more [[physical channel]]..." wikitext text/x-wiki The Communication Cluster specifies the topological connection of communicating [[ECU]]s. In a communication cluster the ECUs are connected by one or more [[physical channel]]s of arbitrary [[topology]]. The ECUs in a communication cluster use the same [[bus protocol]] and address range. b0822cc1ae6133acaebc3da74c8c03be0e5c1897 0 624 913 2014-08-08T08:22:34Z 192.168.2.119 0 Created page with "A computation method that can be used to transform [[fixed-point]] representations of variables in the [[ECU]] memory into corresponding [[physical value]]s and vice versa." wikitext text/x-wiki A computation method that can be used to transform [[fixed-point]] representations of variables in the [[ECU]] memory into corresponding [[physical value]]s and vice versa. 93dc1c3058c7d51bf98686074f4781f5d7c85dfa 955 913 2014-08-11T07:01:51Z Oliver 1 wikitext text/x-wiki A computation method that can be used to transform [[fixed-point]] representations of variables in the [[ECU]] memory into corresponding [[physical value]]s and vice versa. Compu methods define the relationship between internal values of the [[Software Component]] on the target ECU and converted values (real-world, physical). 60ef3b9372898b6d7b5d9c3df479793839fc4e81 957 955 2014-08-11T07:05:12Z Oliver 1 wikitext text/x-wiki A computation method that can be used to transform [[fixed-point]] representations of variables in the [[ECU]] memory into corresponding [[physical value]]s and vice versa. Compu methods define the relationship between internal values of the [[Software Component]] on the target ECU and converted values (real-world, physical). Compu methods are optional (not mandatory) for [[port interface]]s. dc7c43ea775bab741296fdbfb057d6196313bb24 0 625 914 2014-08-08T08:24:24Z 192.168.2.119 0 Redirected page to [[Data constraint]] wikitext text/x-wiki #REDIRECT [[data constraint]] cd96142d27b1c16fa7fff096e341af267a01577b 0 626 915 2014-08-08T08:25:19Z 192.168.2.119 0 Created page with "A data constraint is an element that restricts the range of a [[data type]]. Data constraints are used in conjunction with [[port]]s and [[interface]]s." wikitext text/x-wiki A data constraint is an element that restricts the range of a [[data type]]. Data constraints are used in conjunction with [[port]]s and [[interface]]s. 2f5644a8c6e290def276c9951bdc3a6f7f229f9e 956 915 2014-08-11T07:04:48Z Oliver 1 wikitext text/x-wiki A data constraint is an element that restricts the range of a [[data type]]. Data constraints are used in conjunction with [[port]]s and [[interface]]s. By using a data constr element one can also specify a minimum and maximum value to define the range of values for a data type. Data constraints are optional (not mandatory) for [[port interface]]s. b6c5737c5ac4dfeda7d5ad310d5ddc4593033468 963 956 2014-08-11T09:38:53Z Oliver 1 wikitext text/x-wiki A data constraint is an element that restricts the range of a [[data type]]. Data constraints are used in conjunction with [[port]]s and [[interface]]s. By using a data constr element one can also specify a minimum and maximum value to define the range of values for a data type. Data constraints are optional (not mandatory) for [[port interface]]s. You can constrain the [[physical value]]s of a [[data type]] with a data constr element. 6e95ff69fa4c57f6a812f6ca81e2d351d3017d82 0 148 916 163 2014-08-08T08:27:08Z 192.168.2.119 0 wikitext text/x-wiki Data elements are declared within the context of a [[Sender-Receiver Interface]]. They serve as the data units that are exchanged between [[sender]] and [[receiver]]. Data elements are information units that are exchanged between [[provide port]]s and [[require port]]s via a Sender-Receiver Interface. They represent the data flow. 1bd67d48456aa54ad205f651795be3dc5634b953 0 326 917 380 2014-08-08T08:28:14Z 192.168.2.119 0 wikitext text/x-wiki A Software Signal is an asynchronous [[event]] transmitted between one [[process]] and another. A SW Signal is the software implementation of an (control-) information. Additionally it may have attributes (e.g. freshness, [[data type]], …). It is exchanged between [[Software Component]]s. 32462b5050d034e3bbeb3441e362801fd8935e7a 0 627 918 2014-08-08T08:36:48Z 192.168.2.119 0 Redirected page to [[Data type#Implementation Data Type]] wikitext text/x-wiki #REDIRECT [[data type#Implementation Data Type]] e3171653e15535d90d31dd18dcad29e14354d679 0 628 919 2014-08-08T08:37:08Z 192.168.2.119 0 Redirected page to [[Data type#Application Data Type]] wikitext text/x-wiki #REDIRECT [[data type#Application Data Type]] bb8dd327afb4db92896ef79fa139c6fc2f7624fa 0 144 921 900 2014-08-08T08:52:55Z 192.168.2.119 0 /* Assembly Connector */ wikitext text/x-wiki A connector symbolizes the data flow from one [[PPort]] to one [[RPort]] of [[Software Component]]s (SW-C) or [[Software composition]]s. There are two types of connectors = Assembly Connector = Assembly connectors connect ports of [[Software Component]]s (SW-C). During the design of an [[AUTOSAR system]], ports between Software Components that need to communicate with each other are hooked up using Assembly Connectors. Such an Assembly Connector connects one SW-C with another SW-C. = Delegation Connector = Delegation connectors connect the Software Composition with its inner Software Components. During the design of an [[AUTOSAR system]], ports between Software Components that need to communicate with each other are hooked up using Assembly Connectors. Such an Assembly Connector connects one 2bca807cef180c7d63f27106fafef4f8ecb24c2f 922 921 2014-08-08T08:55:20Z 192.168.2.119 0 /* Delegation Connector */ wikitext text/x-wiki A connector symbolizes the data flow from one [[PPort]] to one [[RPort]] of [[Software Component]]s (SW-C) or [[Software composition]]s. There are two types of connectors = Assembly Connector = Assembly connectors connect ports of [[Software Component]]s (SW-C). During the design of an [[AUTOSAR system]], ports between Software Components that need to communicate with each other are hooked up using Assembly Connectors. Such an Assembly Connector connects one SW-C with another SW-C. = Delegation Connector = Delegation connectors connect the [[port]]s of a [[Software Composition]] with the ports of its inner [[Software Component]]s. b584408598b9c9c9f98018be5e1fdf4f9a34d516 923 922 2014-08-08T08:56:55Z 192.168.2.119 0 wikitext text/x-wiki A connector symbolizes the data flow from one [[PPort]] to one [[RPort]] of [[Software Component]]s (SW-C) or [[Composition Software Component|Software composition]]s. There are two types of connectors = Assembly Connector = Assembly connectors connect ports of [[Software Component]]s (SW-C). During the design of an [[AUTOSAR system]], ports between Software Components that need to communicate with each other are hooked up using Assembly Connectors. Such an Assembly Connector connects one SW-C with another SW-C. = Delegation Connector = Delegation connectors connect the [[port]]s of a [[Software Composition]] with the ports of its inner [[Software Component]]s. 07abcd4ac798383ba9bd8c54f18384b7872a82aa 0 157 924 509 2014-08-08T09:03:19Z 192.168.2.119 0 wikitext text/x-wiki [[Activity]] of integrating and configuring one [[ECU]]’s software. Further Explanations: ECU Configuration denotes the activity when one ECU's software is set up for a specific usage inside the ECU. In AUTOSAR the ECU Configuration activity is divided into [[Pre-compile time]], [[Link time]] and [[Post-build time]] configuration. It is the entire configuration of the [[Basic Software]] and the [[RTE]] of a single [[ECU]]. 6b8f9e55fc31750e9346c08df7e05ec35e1a7288 0 218 925 252 2014-08-08T09:12:38Z 192.168.2.119 0 wikitext text/x-wiki A gateway is functionality within an [[ECU]] that performs a frame or signal mapping function between two [[communication system]]s. Communication system in this context means e.g. a [[CAN]] system or one channel of a [[FlexRay]] system. A gateway allows the exchange of signals between [[communication cluster]]s. An ECU can serve as a gateway if it is connected to two or more different communication clusters. 7be8368f223a6907c6f84ed878ba1877001a754d 0 240 926 836 2014-08-08T09:13:57Z 192.168.2.119 0 wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. There are three different interfaces defined in: * [[AUTOSAR Interface]] * [[Standardized AUTOSAR Interface]] * [[Standardized Interface]] Each [[port]] on a [[Software Component]] has to have an interface assigned. ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf * page 59 "Components and interfaces view (simplified)".'' * page 60 "General Interfacing Rules" 8c9d38d47ac79693b9bdbe9f391646c2524bb927 930 926 2014-08-08T11:32:35Z 192.168.2.119 0 wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. Each [[port]] on a [[Software Component]] has to have an interface assigned. An interface is attached to a [[port]] and describes the data or [[operation]]s that are provided or required by a [[software component]] via that port. ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf * page 59 "Components and interfaces view (simplified)".'' * page 60 "General Interfacing Rules" There are three different interfaces defined in: = [[AUTOSAR Interface]] = = [[Standardized AUTOSAR Interface]] = = [[Standardized Interface]] = a03df3a30f11a483ac8cdb57a4fbfecff84504ff 931 930 2014-08-08T11:37:59Z 192.168.2.119 0 wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. = Port Interface = Each [[port]] on a [[Software Component]] has to have a port-interface assigned. An interface is attached to a [[port]] and describes the data or [[operation]]s that are provided or required by a [[software component]] via that port. A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[Client-Server communication]] is chosen or a [[Sender-Receiver Interface]] in case [[Sender-Receiver communication]] is used. Further more it can also be a [[Parameter Interface]], [[Non Volatile Data Interface]], [[Trigger Interface]] or [[Mode Switch Interface]]. It defines the contract that must be fulfilled by the port providing or requiring that interface. = Sender-Receiver Interface = A sender-receiver interface is a special kind of [[port-interface]] used for the case of [[sender-receiver communication]]. The sender-receiver interface defines the [[data-element]]s which are sent by a sending [[component]] (which has a [[p-port]] providing the sender-receiver interface) or received by a receiving component (which has an [[r-port]] requiring the sender-receiver interface). ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf * page 59 "Components and interfaces view (simplified)".'' * page 60 "General Interfacing Rules" There are three different interfaces defined in: = [[AUTOSAR Interface]] = = [[Standardized AUTOSAR Interface]] = = [[Standardized Interface]] = 5b985951123f29c36d7a2e1a7cb615667cbdb12c 935 931 2014-08-08T11:40:50Z 192.168.2.119 0 wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. = Port Interface = Each [[port]] on a [[Software Component]] has to have a port-interface assigned. An interface is attached to a [[port]] and describes the data or [[operation]]s that are provided or required by a [[software component]] via that port. A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[Client-Server communication]] is chosen or a [[Sender-Receiver Interface]] in case [[Sender-Receiver communication]] is used. Further more it can also be a [[Parameter Interface]], [[Non Volatile Data Interface]], [[Trigger Interface]] or [[Mode Switch Interface]]. It defines the contract that must be fulfilled by the port providing or requiring that interface. = Sender-Receiver Interface = A sender-receiver (S/R) interface is a special kind of [[port-interface]] used for the case of [[sender-receiver communication]]. The sender-receiver interface defines the [[data-element]]s which are sent by a sending [[component]] (which has a [[p-port]] providing the sender-receiver interface) or received by a receiving component (which has an [[r-port]] requiring the sender-receiver interface). = Client-Server Interface = ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf * page 59 "Components and interfaces view (simplified)".'' * page 60 "General Interfacing Rules" There are three different interfaces defined in: = AUTOSAR Interface = The AUTOSAR Interface of a software component ([[SW-C]]) refers to the collection of all [[port]]s of that component through which it interacts with other components. An AUTOSAR Interface defines the information exchanged between software components and/or [[BSWM|BSW Modules]]. This description is independent of a specific programming language, [[ECU]] or network technology. AUTOSAR Interfaces are used in defining the ports of software-components and/or BSW modules. Through these ports software-components and/or BSW modules can communicate with each other (send or receive information or invoke services). AUTOSAR makes it possible to implement this communication between SW-C and/or BSW modules either locally or via a [[network]]. = Standardized AUTOSAR Interface = This is an AUTOSAR Interface which is standardized within the AUTOSAR project. AUTOSAR [[Service]]s interact with other [[Software Component]]s through a Standardized AUTOSAR Interface. A Standardized AUTOSAR Interface is an [[AUTOSAR Interface]] whose syntax and semantics are standardized in AUTOSAR. The Standardized AUTOSAR Interfaces are typically used to define [[AUTOSAR Service]]s, which are standardized [[service]]s provided by the AUTOSAR [[Basic Software]] to the application Software Components. = Standardized Interface = A software [[interface]] is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[Basic Software]] interact which each other through Standardized Interfaces. A Standardized Interface is an [[API]] which is standardized within AUTOSAR without using the [[AUTOSAR Interface]] technique. These "Standardized Interfaces" are typically defined for a specific programming language (like "C"). Because of this, "standardized interfaces" are typically used between Software Modules which are always on the same [[ECU]]. When software modules communicate through a "standardized interface", it is NOT possible any more to route the communication between the software-modules through a network. 4be8fd6519f22a54530ecf4663a5667aeb6785e7 939 935 2014-08-08T11:43:36Z 192.168.2.119 0 wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. = Port Interface = Each [[port]] on a [[Software Component]] has to have a port-interface assigned. An interface is attached to a [[port]] and describes the data or [[operation]]s that are provided or required by a [[software component]] via that port. A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[Client-Server communication]] is chosen or a [[Sender-Receiver Interface]] in case [[Sender-Receiver communication]] is used. Further more it can also be a [[Parameter Interface]], [[Non Volatile Data Interface]], [[Trigger Interface]] or [[Mode Switch Interface]]. It defines the contract that must be fulfilled by the port providing or requiring that interface. = Sender-Receiver Interface = A sender-receiver (S/R) interface is a special kind of [[port-interface]] used for the case of [[sender-receiver communication]]. The sender-receiver interface defines the [[data-element]]s which are sent by a sending [[component]] (which has a [[p-port]] providing the sender-receiver interface) or received by a receiving component (which has an [[r-port]] requiring the sender-receiver interface). = Client-Server Interface = = Types of interfaces within [[Basic Software]] = ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf * page 59 "Components and interfaces view (simplified)".'' * page 60 "General Interfacing Rules" There are three different interfaces defined in: == AUTOSAR Interface == The AUTOSAR Interface of a software component ([[SW-C]]) refers to the collection of all [[port]]s of that component through which it interacts with other components. An AUTOSAR Interface defines the information exchanged between software components and/or [[BSWM|BSW Modules]]. This description is independent of a specific programming language, [[ECU]] or network technology. AUTOSAR Interfaces are used in defining the ports of software-components and/or BSW modules. Through these ports software-components and/or BSW modules can communicate with each other (send or receive information or invoke services). AUTOSAR makes it possible to implement this communication between SW-C and/or BSW modules either locally or via a [[network]]. == Standardized AUTOSAR Interface == This is an AUTOSAR Interface which is standardized within the AUTOSAR project. AUTOSAR [[Service]]s interact with other [[Software Component]]s through a Standardized AUTOSAR Interface. A Standardized AUTOSAR Interface is an [[AUTOSAR Interface]] whose syntax and semantics are standardized in AUTOSAR. The Standardized AUTOSAR Interfaces are typically used to define [[AUTOSAR Service]]s, which are standardized [[service]]s provided by the AUTOSAR [[Basic Software]] to the application Software Components. == Standardized Interface == A software [[interface]] is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[Basic Software]] interact which each other through Standardized Interfaces. A Standardized Interface is an [[API]] which is standardized within AUTOSAR without using the [[AUTOSAR Interface]] technique. These "Standardized Interfaces" are typically defined for a specific programming language (like "C"). Because of this, "standardized interfaces" are typically used between Software Modules which are always on the same [[ECU]]. When software modules communicate through a "standardized interface", it is NOT possible any more to route the communication between the software-modules through a network. 426a4bc79cd736e264b28599addcbb141ae27586 940 939 2014-08-08T11:49:05Z 192.168.2.119 0 /* Sender-Receiver Interface */ wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. = Port Interface = Each [[port]] on a [[Software Component]] has to have a port-interface assigned. An interface is attached to a [[port]] and describes the data or [[operation]]s that are provided or required by a [[software component]] via that port. A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[Client-Server communication]] is chosen or a [[Sender-Receiver Interface]] in case [[Sender-Receiver communication]] is used. Further more it can also be a [[Parameter Interface]], [[Non Volatile Data Interface]], [[Trigger Interface]] or [[Mode Switch Interface]]. It defines the contract that must be fulfilled by the port providing or requiring that interface. = Sender-Receiver Interface = A sender-receiver (S/R) interface is a special kind of [[port-interface]] used for the case of [[sender-receiver communication]]. The sender-receiver interface defines the [[data-element]]s which are sent by a sending [[component]] (which has a [[p-port]] providing the sender-receiver interface) or received by a receiving component (which has an [[r-port]] requiring the sender-receiver interface). Sender-Receiver interfaces are used for data exchange between software components. The interface specifies which data is transferred from the sender to the receiver. It is composed of variable data prototypes and specifies the transferred data. The variable data prototypes are of a type which describes the possible values of a variable on physical and internal level. The internal values of the data type can be converted to physical values via a [[compu method]]. The range of the values can be restricted with [[data constr]] elements. = Client-Server Interface = = Types of interfaces within [[Basic Software]] = ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf * page 59 "Components and interfaces view (simplified)".'' * page 60 "General Interfacing Rules" There are three different interfaces defined in: == AUTOSAR Interface == The AUTOSAR Interface of a software component ([[SW-C]]) refers to the collection of all [[port]]s of that component through which it interacts with other components. An AUTOSAR Interface defines the information exchanged between software components and/or [[BSWM|BSW Modules]]. This description is independent of a specific programming language, [[ECU]] or network technology. AUTOSAR Interfaces are used in defining the ports of software-components and/or BSW modules. Through these ports software-components and/or BSW modules can communicate with each other (send or receive information or invoke services). AUTOSAR makes it possible to implement this communication between SW-C and/or BSW modules either locally or via a [[network]]. == Standardized AUTOSAR Interface == This is an AUTOSAR Interface which is standardized within the AUTOSAR project. AUTOSAR [[Service]]s interact with other [[Software Component]]s through a Standardized AUTOSAR Interface. A Standardized AUTOSAR Interface is an [[AUTOSAR Interface]] whose syntax and semantics are standardized in AUTOSAR. The Standardized AUTOSAR Interfaces are typically used to define [[AUTOSAR Service]]s, which are standardized [[service]]s provided by the AUTOSAR [[Basic Software]] to the application Software Components. == Standardized Interface == A software [[interface]] is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[Basic Software]] interact which each other through Standardized Interfaces. A Standardized Interface is an [[API]] which is standardized within AUTOSAR without using the [[AUTOSAR Interface]] technique. These "Standardized Interfaces" are typically defined for a specific programming language (like "C"). Because of this, "standardized interfaces" are typically used between Software Modules which are always on the same [[ECU]]. When software modules communicate through a "standardized interface", it is NOT possible any more to route the communication between the software-modules through a network. 40011a29d9fe498d8eae2ca333073f09f55aef37 961 940 2014-08-11T09:32:45Z Oliver 1 /* Client-Server Interface */ wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. = Port Interface = Each [[port]] on a [[Software Component]] has to have a port-interface assigned. An interface is attached to a [[port]] and describes the data or [[operation]]s that are provided or required by a [[software component]] via that port. A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[Client-Server communication]] is chosen or a [[Sender-Receiver Interface]] in case [[Sender-Receiver communication]] is used. Further more it can also be a [[Parameter Interface]], [[Non Volatile Data Interface]], [[Trigger Interface]] or [[Mode Switch Interface]]. It defines the contract that must be fulfilled by the port providing or requiring that interface. = Sender-Receiver Interface = A sender-receiver (S/R) interface is a special kind of [[port-interface]] used for the case of [[sender-receiver communication]]. The sender-receiver interface defines the [[data-element]]s which are sent by a sending [[component]] (which has a [[p-port]] providing the sender-receiver interface) or received by a receiving component (which has an [[r-port]] requiring the sender-receiver interface). Sender-Receiver interfaces are used for data exchange between software components. The interface specifies which data is transferred from the sender to the receiver. It is composed of variable data prototypes and specifies the transferred data. The variable data prototypes are of a type which describes the possible values of a variable on physical and internal level. The internal values of the data type can be converted to physical values via a [[compu method]]. The range of the values can be restricted with [[data constr]] elements. = Client-Server Interface = The client-server interface is a special kind of [[port-interface]] used for the case of [[client-server communication]]. The client-server interface defines the operations that are provided (implemented) by the [[server]] and that can be used by the [[client]]. Client-server interfaces allow a client to call an operation at a server, which in turn provides the result to the client. The [argument data prototype]]s of the operation of an interface can be the client input to the server (IN) or the server result (OUT) or both (INOUT). = Types of interfaces within [[Basic Software]] = ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf * page 59 "Components and interfaces view (simplified)".'' * page 60 "General Interfacing Rules" There are three different interfaces defined in: == AUTOSAR Interface == The AUTOSAR Interface of a software component ([[SW-C]]) refers to the collection of all [[port]]s of that component through which it interacts with other components. An AUTOSAR Interface defines the information exchanged between software components and/or [[BSWM|BSW Modules]]. This description is independent of a specific programming language, [[ECU]] or network technology. AUTOSAR Interfaces are used in defining the ports of software-components and/or BSW modules. Through these ports software-components and/or BSW modules can communicate with each other (send or receive information or invoke services). AUTOSAR makes it possible to implement this communication between SW-C and/or BSW modules either locally or via a [[network]]. == Standardized AUTOSAR Interface == This is an AUTOSAR Interface which is standardized within the AUTOSAR project. AUTOSAR [[Service]]s interact with other [[Software Component]]s through a Standardized AUTOSAR Interface. A Standardized AUTOSAR Interface is an [[AUTOSAR Interface]] whose syntax and semantics are standardized in AUTOSAR. The Standardized AUTOSAR Interfaces are typically used to define [[AUTOSAR Service]]s, which are standardized [[service]]s provided by the AUTOSAR [[Basic Software]] to the application Software Components. == Standardized Interface == A software [[interface]] is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[Basic Software]] interact which each other through Standardized Interfaces. A Standardized Interface is an [[API]] which is standardized within AUTOSAR without using the [[AUTOSAR Interface]] technique. These "Standardized Interfaces" are typically defined for a specific programming language (like "C"). Because of this, "standardized interfaces" are typically used between Software Modules which are always on the same [[ECU]]. When software modules communicate through a "standardized interface", it is NOT possible any more to route the communication between the software-modules through a network. 3968eda01f9bca148f092791948d4a167cec68c5 0 630 927 2014-08-08T09:15:42Z 192.168.2.119 0 Created page with "Modeling element for specifying communication between the runnable entities in one [[atomic software component]]." wikitext text/x-wiki Modeling element for specifying communication between the runnable entities in one [[atomic software component]]. 984455a71dc58696a87976c0a3c127d79db2a0f6 0 631 928 2014-08-08T09:16:30Z 192.168.2.119 0 Redirected page to [[Interrunnable variable]] wikitext text/x-wiki #REDIRECT [[interrunnable variable]] 635d0f7598fe363ef11ab12f3dcdb3329271fc72 0 632 929 2014-08-08T09:17:21Z 192.168.2.119 0 Redirected page to [[I-PDU]] wikitext text/x-wiki #REDIRECT [[I-PDU]] 5aaf5eed345b214f2a453ec5b12795dd12f0a885 0 313 932 367 2014-08-08T11:38:50Z 192.168.2.119 0 Redirected page to [[Interface#Sender-Receiver Interface]] wikitext text/x-wiki #REDIRECT [[Interface#Sender-Receiver Interface]] bf2fef23b13a98590dfd26f6fa64a08db5e87a87 0 276 933 457 2014-08-08T11:38:57Z 192.168.2.119 0 Redirected page to [[Interface#Port Interface]] wikitext text/x-wiki #REDIRECT [[Interface#Port Interface]] 8f2e61ad0a663ade8903a49502a0ee172cc6d587 0 379 934 453 2014-08-08T11:39:02Z 192.168.2.119 0 Redirected page to [[Interface#Port Interface]] wikitext text/x-wiki #REDIRECT [[Interface#Port Interface]] 8f2e61ad0a663ade8903a49502a0ee172cc6d587 0 112 936 738 2014-08-08T11:41:16Z 192.168.2.119 0 Redirected page to [[Interface#AUTOSAR Interface]] wikitext text/x-wiki #REDIRECT [[Interface#AUTOSAR Interface]] 4c411e26f735d8f82aba4905d25efabfa2a29f4b 0 329 937 741 2014-08-08T11:41:46Z 192.168.2.119 0 Redirected page to [[Interface#Standardized AUTOSAR Interface]] wikitext text/x-wiki #REDIRECT [[Interface#Standardized AUTOSAR Interface]] 8859e259fe5067efbe241b48a90df368746040c2 0 330 938 743 2014-08-08T11:41:56Z 192.168.2.119 0 Redirected page to [[Interface#Standardized Interface]] wikitext text/x-wiki #REDIRECT [[Interface#Standardized Interface]] a39741d27d96ec08f76fa7e772fce9f9e7fd5977 0 633 941 2014-08-08T19:43:07Z 192.168.2.119 0 Created page with "The IsService flag on an [[interface]] indicate whether the [[Client-Server Interface]] is provided by a [[Basic Software Module]]." wikitext text/x-wiki The IsService flag on an [[interface]] indicate whether the [[Client-Server Interface]] is provided by a [[Basic Software Module]]. 2fa04d7d554f889b8de79085f71b05389b6173ee 0 634 942 2014-08-08T19:44:46Z 192.168.2.119 0 Created page with "ISignal is an element that represents a system [[signal]] in the [[Interaction Layer]]. ISignals let the user define network communication on signal level without having to de..." wikitext text/x-wiki ISignal is an element that represents a system [[signal]] in the [[Interaction Layer]]. ISignals let the user define network communication on signal level without having to define [[PDU]]s or [[frame]]s. 0015a13a935ad9264912cef28aa95686acc2402d 943 942 2014-08-08T19:46:51Z 192.168.2.119 0 wikitext text/x-wiki ISignal is an element that represents a system [[signal]] in the [[Interaction Layer]]. ISignals let the user define network communication on signal level without having to define [[PDU]]s or [[frame]]s. If a system signal is assigned to several [[IPDU]]s then each assignment requires a separate ISignal. The mapping of an ISignal to signal IPDUs and the location of an ISignal within a signal IPDU is defined by [[signal instance]]. 26e8710f419870287408fb191a747790ca8cebfe 0 635 944 2014-08-08T19:48:13Z 192.168.2.119 0 Created page with "MemMap configuration is the configuration of the [[MemMap module]] for one [[ECU]]. The MemMap configuration is part of the [[ECU configuration]]." wikitext text/x-wiki MemMap configuration is the configuration of the [[MemMap module]] for one [[ECU]]. The MemMap configuration is part of the [[ECU configuration]]. 3a537579c97a99526b2e7232fa2d4cd17d3380a7 0 383 945 461 2014-08-08T19:50:35Z 192.168.2.119 0 wikitext text/x-wiki The mode switch [[interface]] is used to notify a [[Software Component]] of a [[mode]]. The [[Mode Manager]] provides modes that can be used by [[mode user]]s to adjust the behavior according to modes or synchronize activities to mode switches. It is an interface that contains a [[mode declaration group]]. Via a mode switch interface a Software Component can get information on a mode switch. 1110c2b01cdf598f7646ddfb7f8ab65136c5db9f 0 636 946 2014-08-08T19:51:35Z 192.168.2.119 0 Created page with "The mode declaration group is an element that contains the possible [[operating state]]s of an [[ECU]], single functional unit, etc." wikitext text/x-wiki The mode declaration group is an element that contains the possible [[operating state]]s of an [[ECU]], single functional unit, etc. 340b705255605de0471c79879a599e452a4b31cf 0 637 947 2014-08-08T19:52:53Z 192.168.2.119 0 Created page with "The NvM configuration is the configuration of the [[NVRAM Manager Module]] for one ECU. An NvM configuration is part of an [[ECU configuration]]." wikitext text/x-wiki The NvM configuration is the configuration of the [[NVRAM Manager Module]] for one ECU. An NvM configuration is part of an [[ECU configuration]]. f0252b90a3f0f297d7db214f6ae3409a7ce1ca5e 0 638 948 2014-08-08T19:54:09Z 192.168.2.119 0 Created page with "The OS configuration is the configuration of the [[operating system]] for one ECU. An OS configuration is part of an [[ECU configuration]]." wikitext text/x-wiki The OS configuration is the configuration of the [[operating system]] for one ECU. An OS configuration is part of an [[ECU configuration]]. 4d892cde36a7565cef6f6459c217e6b9185cd0b1 0 639 949 2014-08-08T19:55:10Z 192.168.2.119 0 Redirected page to [[Task]] wikitext text/x-wiki #REDIRECT [[Task]] a0aef0aab6cf01ac179cc424503886177b63e0dc 0 339 950 495 2014-08-08T20:01:00Z 192.168.2.119 0 wikitext text/x-wiki = OS = A Task is the smallest schedulable unit managed by the [[OS]]. The OS decides when which task can run on the [[CPU]] of the [[ECU]]. A [[runnable entity]] of a [[software component]] runs in the context of a task. Also the [[Basic Software Module]]s runs in the context of a task. The OS task is an element that provided the framework for executing the [[ECU application]]. It can be executed [concurrently]] with other tasks. The [[task scheduler]] of the operating system controls the execution of an OS task according to the [[task priority]] and the task scheduling policy. == Basic Task == A basic task has a defined beginning and defined end. It releases the processor only if it is being terminated or if the operating system is executing a task with higher priority or if an [[interrupt]] occurs. A basic task can enter only the task states '''suspended''', '''ready''' and '''running'''. It cannot wait for [[OS events]]. == Extended Task == Unlike a basic task an extended task can also enter the '''waiting''' task state in which it can wait for an OS event. = Methodology = According to the [[SPEM]] [[meta model]], a Task Definition is an assignable unit of work that is being performed by specific [[Role]]s. The duration of a task is generally a few hours to a few days. Tasks usually generate one or more [[work product]]s. Each Task is associated to input and output [[Work Product]]s. Inputs are differentiated in mandatory and optional inputs. A Task is used as one element among others to define a [[Process]]. A Task has a clear purpose in which the performing roles achieve a well defined goal. It provides complete step-by-step explanations of doing all the work that needs to be done to achieve this goal. This description is completely independent of when in a process lifecycle the work would actually be done. It does not describe when what work is being done, but describes all the work that gets done. When a Task is used in a process ([[Task Use]]), it provides the information of which pieces of the Task will actually be performed at any particular point in time. This assumes that the Task will be performed in the process over and over again, but each time with a slightly different emphasis on different steps or aspects of the task description. For the [[AUTOSAR Methodology]], a Task is a reusable element that is used across multiple methodology use cases. A Task is associated to at least one performing Role and may have several additional performers. Tasks use Tools to achieve their outputs. Optional performers and optional input and outputs to the task are described by the relationship’s multiplicity. 6cc9d490764ee2be26890b3ca10d64439a8fd526 951 950 2014-08-10T21:47:38Z 192.168.2.119 0 /* Basic Task */ wikitext text/x-wiki = OS = A Task is the smallest schedulable unit managed by the [[OS]]. The OS decides when which task can run on the [[CPU]] of the [[ECU]]. A [[runnable entity]] of a [[software component]] runs in the context of a task. Also the [[Basic Software Module]]s runs in the context of a task. The OS task is an element that provided the framework for executing the [[ECU application]]. It can be executed [concurrently]] with other tasks. The [[task scheduler]] of the operating system controls the execution of an OS task according to the [[task priority]] and the task scheduling policy. == Basic Task == A basic task has a defined beginning and defined end. It releases the processor only if it is being terminated or if the operating system is executing a task with higher priority or if an [[interrupt]] occurs. A basic task can enter only the task states '''suspended''', '''ready''' and '''running'''. It cannot wait for [[OS event]]s. == Extended Task == Unlike a basic task an extended task can also enter the '''waiting''' task state in which it can wait for an OS event. = Methodology = According to the [[SPEM]] [[meta model]], a Task Definition is an assignable unit of work that is being performed by specific [[Role]]s. The duration of a task is generally a few hours to a few days. Tasks usually generate one or more [[work product]]s. Each Task is associated to input and output [[Work Product]]s. Inputs are differentiated in mandatory and optional inputs. A Task is used as one element among others to define a [[Process]]. A Task has a clear purpose in which the performing roles achieve a well defined goal. It provides complete step-by-step explanations of doing all the work that needs to be done to achieve this goal. This description is completely independent of when in a process lifecycle the work would actually be done. It does not describe when what work is being done, but describes all the work that gets done. When a Task is used in a process ([[Task Use]]), it provides the information of which pieces of the Task will actually be performed at any particular point in time. This assumes that the Task will be performed in the process over and over again, but each time with a slightly different emphasis on different steps or aspects of the task description. For the [[AUTOSAR Methodology]], a Task is a reusable element that is used across multiple methodology use cases. A Task is associated to at least one performing Role and may have several additional performers. Tasks use Tools to achieve their outputs. Optional performers and optional input and outputs to the task are described by the relationship’s multiplicity. f779ac79e14483fa21954389c86d5b80df5d216c 0 640 952 2014-08-10T21:49:02Z 192.168.2.119 0 Created page with "An OS event is used to synchronize [[OS task]]s. Extended tasks can suspend their execution without terminating by waiting for OS events. Each task continues when a specific O..." wikitext text/x-wiki An OS event is used to synchronize [[OS task]]s. Extended tasks can suspend their execution without terminating by waiting for OS events. Each task continues when a specific OS event is set. Basic tasks cannot use OS events. 6e2f989222ad705cda77bd3157e4b2385e106dc0 0 166 953 188 2014-08-10T21:49:36Z 192.168.2.119 0 wikitext text/x-wiki State change of a hardware and/or software entity. See also [[OS event]]. 9534d49b84d33527b5e175ba824f0656f6b68ce1 0 312 958 466 2014-08-11T07:12:12Z Oliver 1 wikitext text/x-wiki A communication pattern which offers asynchronous distribution of information where a [[sender]] communicates information to one or more [[receiver]]s, or a receiver receives information from one or several senders. The process of sending data does not block the sender and the sender usually gets no response from the receivers. Both for Sender-Receiver Communication and for [[Client-Server Communication]], one [[PPort]] can be connected to one or more [[RPort]]s (for multicast sending and multiple [[client]]s connected to a [[server]], respectively). Sender-Receiver communication can be queued or non-queued. = Queued S/R communication = If the sender-receiver communication is configured as queued, then the sent data is processed using a first-in-first-out ([[FIFO]]) queue with a specified length. = Non-queued S/R communication = If the sender-receiver communication is configured as non-queued, then the receiver always has access to the last sent data. 53d90b694fa7464c5f28bb362698a6fc5c59d4f5 0 275 959 896 2014-08-11T07:13:45Z Oliver 1 wikitext text/x-wiki A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[Provide Port]] (p-port, PPort) or a [[Require Port]] (r-port, RPort). A port of a SW-C is associated with a [[port-interface]]. The occurrence of an unconnected port is not per se a design mistake. It can be valid when an application provider for the [[data element]] is absent and the default init value is good enough to operate with or it could be that an end point was removed from the [[system]] because it is subjected to variability (See [[Variant Handling]]). Ports are the interconnection points between [[software component]]s. Ports of different SWC can be connected to indicate a data flow between them. The details, i.e. the kind of information that is actually transported between the ports, are defined by [[port-interface]]s. [SystemDesk tutorial] == Unconnected Sender Ports == Data of the sender will not appear on VFB. Generated RTE might simply call empty function or even optimize function call to zero code. == Unconnected Synchronous Receiver Ports == The RPort will always read the initial value specified for this RPort. == Unconnected Asynchronous Receiver Ports == The RPort will receive a time-out like the Sender is not providing data. == Unconnected Server Ports == The operations (functions) of the PPort interface will never be called. Generated RTE (or finally the compiler) might even optimize operation to zero code. == Unconnected Client Ports == According to AUTOSAR specification the [[operation]]s (functions) on the RPort will TIME_OUT. But more likely the [[RTE-Generator]] will generate a return code RTE_E_UNCONNECTED for any unconnected [[client]] interface operation. == Initial (default) values of a port == TODO bdaef49301ce8117bb68363091242956bce07687 0 134 960 462 2014-08-11T09:30:49Z Oliver 1 wikitext text/x-wiki The client-server interface is a special kind of [[port-interface]] used for the case of [[client-server communication]]. The client-server interface defines the operations that are provided (implemented) by the [[server]] and that can be used by the [[client]]. Client-server interfaces allow a client to call an operation at a server, which in turn provides the result to the client. The [argument data prototype]]s of the operation of an [[interface]] can be the client input to the server (IN) or the server result (OUT) or both (INOUT). 56baea5a82cce01d1ff4247c90193bd6c10a9e99 962 960 2014-08-11T09:33:06Z Oliver 1 Redirected page to [[Interface#Client-Server Interface]] wikitext text/x-wiki #REDIRECT [[Interface#Client-Server Interface]] c4f259cc550501302b29f5bc4b54a15dc68e5a24 0 641 964 2014-08-11T09:55:29Z Oliver 1 Created page with "A parameter data prototype specifies an [[ECU]] variable that can be [[calibrate]]d. They can have one of the following roles: * [[Per instance memory]] (PIM) in a Software ..." wikitext text/x-wiki A parameter data prototype specifies an [[ECU]] variable that can be [[calibrate]]d. They can have one of the following roles: * [[Per instance memory]] (PIM) in a [[Software Component]] [[internal behavior]] * [[Shared parameter]] in a Software Component internal behavior * [[Constant memory]] in a Software Component internal behavior * Parameter value in a [[parameter interface]] 4d2cf531bb2e83b5e4d72560cf5a09f12e85fd4a 0 642 965 2014-08-11T09:55:57Z Oliver 1 Redirected page to [[Per instance memory]] wikitext text/x-wiki #REDIRECT [[Per instance memory]] 0bcef7c6b8e9e360cd374c75e1c491582b9cea4c 0 643 966 2014-08-11T09:58:15Z Oliver 1 Created page with "Per instance memory is instantiated for each instance (prototype) of an atomic [[software component]] of the [[RTE]]. A [[data type]] instance can be accessed only by the corr..." wikitext text/x-wiki Per instance memory is instantiated for each instance (prototype) of an atomic [[software component]] of the [[RTE]]. A [[data type]] instance can be accessed only by the corresponding atomic software component instance (prototype). d6a5b39ffc12476afec9cd40143fd8f6cbd81488 0 275 967 959 2014-08-11T10:02:18Z Oliver 1 wikitext text/x-wiki A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[Provide Port]] (p-port, PPort) or a [[Require Port]] (r-port, RPort). A port of a SW-C is associated with a [[port-interface]]. The occurrence of an unconnected port is not per se a design mistake. It can be valid when an application provider for the [[data element]] is absent and the default init value is good enough to operate with or it could be that an end point was removed from the [[system]] because it is subjected to variability (See [[Variant Handling]]). Ports are the interconnection points between [[software component]]s. Ports of different SWC can be connected to indicate a data flow between them. The details, i.e. the kind of information that is actually transported between the ports, are defined by [[port-interface]]s. A port is a part of a software component that is an interaction point between that component and other software components. The interaction between ports is modeled via [[interface]]s. == Unconnected Sender Ports == Data of the sender will not appear on VFB. Generated RTE might simply call empty function or even optimize function call to zero code. == Unconnected Synchronous Receiver Ports == The RPort will always read the initial value specified for this RPort. == Unconnected Asynchronous Receiver Ports == The RPort will receive a time-out like the Sender is not providing data. == Unconnected Server Ports == The operations (functions) of the PPort interface will never be called. Generated RTE (or finally the compiler) might even optimize operation to zero code. == Unconnected Client Ports == According to AUTOSAR specification the [[operation]]s (functions) on the RPort will TIME_OUT. But more likely the [[RTE-Generator]] will generate a return code RTE_E_UNCONNECTED for any unconnected [[client]] interface operation. == Initial (default) values of a port == TODO 41abad1d0bc544c39c1bdcfdb6818697a2862823 0 614 968 895 2014-08-11T10:04:58Z Oliver 1 wikitext text/x-wiki AUTOSAR defines types and prototypes. This concept allows re-using elements (like [[software component]]s, [[data type]]s) several times. E.g. a SW-C type defines the properties of the SW-C together with the [[port]]s, [[internal behavior]] etc. The SW-C prototype is the usage of a SW-C type. The prototype contains all elements and properties of the type plus additional properties such as the shortName. A prototype is referencing a type and reuses it's properties. In analogy to C++ the type would be the class and the prototype the instantiation of this class. dbcce5972ad91624194546e24cfe5033a11ce4d4 0 644 969 2014-08-11T10:05:11Z Oliver 1 Redirected page to [[Types and prototypes]] wikitext text/x-wiki #REDIRECT [[Types and prototypes]] 9765cc148d2fcd0330649472f5f39c0aa246a783 0 645 970 2014-08-11T10:07:24Z Oliver 1 Created page with "The RTE configuration is the configuration of the [[RTE]] for one ECU. An RTE configuration is part of an [[ECU configuration]]." wikitext text/x-wiki The RTE configuration is the configuration of the [[RTE]] for one ECU. An RTE configuration is part of an [[ECU configuration]]. c8b2124c353c82fb43efbdc25d32af55644546da 0 302 971 352 2014-08-11T10:09:43Z Oliver 1 wikitext text/x-wiki An RTE [[Event]] encompasses all possible situations that can trigger execution of a [[runnable entity]] by the [[RTE]]. Thus they can address timing, data sending and receiving, invoking [[operation]]s, call [[server]] returning, [[mode switch]]ing, or external [[event]]s. RTE Events can either activate a runnable entity or wakeup a runnable entity at its [[wait point]]s. Note ‘event’ in this context is not necessarily synonymous with ‘RTEEvent’ as defined in the [[VFB]] specification. In particular, RTE Events that result from communication are handled by communication-triggered runnable entities. An RTE event is part of an SW-C [[internal behavior]]. It defines situations and conditions for starting or continuing the execution of a specific [[runnable entity]]. 3b3fe00412a536509719f72acd0e29815d3b4caa 994 971 2014-08-11T21:43:34Z Oliver 1 wikitext text/x-wiki An RTE [[Event]] encompasses all possible situations that can trigger execution of a [[runnable entity]] by the [[RTE]]. Thus they can address timing, data sending and receiving, invoking [[operation]]s, call [[server]] returning, [[mode switch]]ing, or external [[event]]s. RTE Events can either activate a runnable entity or wakeup a runnable entity at its [[wait point]]s. Note ‘event’ in this context is not necessarily synonymous with ‘RTEEvent’ as defined in the [[VFB]] specification. In particular, RTE Events that result from communication are handled by communication-triggered runnable entities. An RTE event is part of an SW-C [[internal behavior]]. It defines situations and conditions for starting or continuing the execution of a specific [[runnable entity]]. = Timing event = Triggers a [[runnable entity]] periodically = Data received event = Triggers a runnable entity as soon as a [[variable data prototype]] is received at the [[port]]. 202de569264c668b82c322d869a3748770451d35 0 111 973 907 2014-08-11T10:14:28Z Oliver 1 wikitext text/x-wiki Non-composed [[Software Component]] (SW-C). An Atomic Software Component might access [[HW]] or not, therefore not all Atomic SW-Cs are re-locatable. Any [[Software Component]] that can contain a SW-C [[internal behavior]]. An Atomic Software Component communicates with the outside via the [[interface]]s at the SW-C [[port]]s. 91522d3c8ca0e191128dfdc55ae5473cc9729ce9 999 973 2014-08-11T22:05:37Z Oliver 1 wikitext text/x-wiki Non-composed [[Software Component]] (SW-C). An Atomic Software Component might access [[HW]] or not, therefore not all Atomic SW-Cs are re-locatable. Any [[Software Component]] that can contain a SW-C [[internal behavior]]. An Atomic Software Component communicates with the outside via the [[interface]]s at the SW-C [[port]]s. Interrunnable communication is used for communication between runnables of the same SW-C. The [[runnable entity|runnable entities]] have access to the same [[interrunnable variable]]. fee82a763e60f0c80d30742bccab395a4bf4f282 0 314 974 447 2014-08-11T10:17:54Z Oliver 1 wikitext text/x-wiki [[Software Component]] dedicated to the control of a [[sensor]] or [[actuator]]. There will be several Sensor/ Actuator SW-Cs in each [[ECU]]. In general there will be one Sensor/Actuator SW-C for each sensor and one for each actuator (=> number of Sensor/Actuator SW-C = number of sensors + number of actuators). An [[Atomic Software Component]] that links from the software representation of a sensor/actuator to its [[hardware interface]] provided by the [[Basic Software]]. It has to be mapped to the ECU where the hardware is physically present. e3118b473112de6fc2b6de7339ee5c0fb77b7a06 0 392 975 483 2014-08-11T10:23:08Z Oliver 1 wikitext text/x-wiki A Service [[Software Component]] provides standardized [[service]]s through [[Standardized Interface]]s. To provide these services, this component may interact directly with certain other [[Basic Software Module]]s. An [[Atomic Software Component]] that provides service functionality via [[Interface#Standardized AUTOSAR interface|Standardized AUTOSAR interface]]s. It describes a specific Software Component which is part of the [[Basic Software]] and provides services of a specific [[ECU]]. Service component [[port]]s are connected to [[Application Software Component]]s via specific connectors. 40a674bc523ea4cda3c82cae05889315d4dfecd2 0 646 976 2014-08-11T10:26:30Z Oliver 1 Created page with "A shared parameter is a [[parameter data prototype]] that is defined at the Software Component [[internal behavior]] of a [[Software Component]] and is shared by all the ins..." wikitext text/x-wiki A shared parameter is a [[parameter data prototype]] that is defined at the Software Component [[internal behavior]] of a [[Software Component]] and is shared by all the [[instance]]s of the component. c92ebc0dd43aebf3754837bbbcb12b4005097cd9 0 320 977 535 2014-08-11T11:14:05Z Oliver 1 wikitext text/x-wiki Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Functional Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the Software Component [[template]]. Software Components can be abbreviated as SW-Cs. A SW-C contains a [[Software Component Description]] (SWCD) and the [[Software Component Implementation|implementation]]. 0c29d937cae3388eaf573f78306f1142d80ac6fe 0 647 978 2014-08-11T11:16:54Z Oliver 1 Created page with "The [[Software Component]] implementation describes how a specific SW-C [[internal behavior]] is realized for a given platform ([[microcontroller]] type and [[compiler]]. A SW..." wikitext text/x-wiki The [[Software Component]] implementation describes how a specific SW-C [[internal behavior]] is realized for a given platform ([[microcontroller]] type and [[compiler]]. A SW-C implementation mainly consists of a list of source files, object files, compiler attributes and dependencies between the make and [[build process]]. ff34f512cb47de057e91d75ac82816017ea02476 0 648 979 2014-08-11T11:17:24Z Oliver 1 Redirected page to [[Software Component Internal behavior]] wikitext text/x-wiki #REDIRECT [[Software Component Internal behavior]] 286543d9f37dd1dbb87bd3f16021c0abded9460c 0 649 980 2014-08-11T11:21:40Z Oliver 1 Created page with "The [[Software Component]] internal behavior represents the internal structure of an [[Atomic Software Component]]. It is characterized by its runnable entity|runnable entit..." wikitext text/x-wiki The [[Software Component]] internal behavior represents the internal structure of an [[Atomic Software Component]]. It is characterized by its [[runnable entity|runnable entities]], [[RTE Event]]s, [[exclusive area]]s, [[Per instance memory]] and their interdependencies. 3db15de40f29bbcd5d408169095b923a1c480bac 989 980 2014-08-11T21:19:38Z Oliver 1 wikitext text/x-wiki The [[Software Component]] internal behavior represents the internal structure of an [[Atomic Software Component]]. It is characterized by its [[runnable entity|runnable entities]], [[RTE Event]]s, [[exclusive area]]s, [[Per instance memory]] and their interdependencies. The internal behavior is an element that represents the internal structure of an [[Atomic Software Component]]. It is characterized by [[elements]] such as * [[runnable entity|runnable entities]] * [[RTE Event]]s * [[data access definition]]s * [[interrunnable variable]]s and their interdependencies. A SW-C internal behavior is refined by a [[Software Component Implementation]]. d25a5a92baac372c978d65410e807015a86a83fe 0 338 981 394 2014-08-11T11:24:09Z Oliver 1 wikitext text/x-wiki The system [[signal]] represents the communication system's view of data exchanged between [[Software component]]s which reside on different [[ECU]]s. The [[system]] signals allow to represent this communication in a flattened structure, with (at least) one system signal defined for each data element sent or received by a SW component instance. If data has to be sent over gateways, there is still only one system signal representing this data. The representation of the data on the individual communication systems is done by the cluster signals. The system signal is an element for network communication that represents a data element exchanged between software components residing on different ECUs. It can be assigned to one or more [[I-PDU]]s. adbfa7eb88c69595cc3a2975e8ab20326967d4e4 0 650 982 2014-08-11T11:26:22Z Oliver 1 Created page with "A group of [[System Signal]]s that must always be kept together to guarantee the [[atomic transfer]] of AUTOSAR [[composite data type]]s." wikitext text/x-wiki A group of [[System Signal]]s that must always be kept together to guarantee the [[atomic transfer]] of AUTOSAR [[composite data type]]s. 44194ba19ae567cb0a585d8d6ef26daf8847f23f 0 651 983 2014-08-11T11:28:16Z Oliver 1 Created page with "A Unit can be referenced at an [[application data type]] or [[compu method]] to specify the unit of its values. This is necessary for correct interpretation of the physical ..." wikitext text/x-wiki A Unit can be referenced at an [[application data type]] or [[compu method]] to specify the unit of its values. This is necessary for correct interpretation of the [[physical value]]. 02f5b54561630109781d2ce6347bff1b5bd57b7c 0 652 984 2014-08-11T11:32:01Z Oliver 1 Created page with "A variable data prototype is an element that is used to contain values in an [[ECU application]]. They can have one of the following roles: * [[Data element] in a Sender-Rec..." wikitext text/x-wiki A variable data prototype is an element that is used to contain values in an [[ECU application]]. They can have one of the following roles: * [[Data element] in a [[Sender-Receiver Interface]] * [[Interrunnable variable]] in a [[Software Component]] [[internal behavior]] * [[Per instance memory]] in a Software Component internal behavior * [[Static memory]] in a Software Component internal behavior 050e8586ec0b42013fb009ae864d18b67dfbcd5f 0 575 985 827 2014-08-11T11:32:54Z Oliver 1 wikitext text/x-wiki Libraries are a collection of functions for related purposes. They * can be called by [[BSW module]]s (that including the [[RTE]]), [[SW-C]]s, libraries or integration code * run in the [[context]] of the caller in the same [[protection environment]] * can only call libraries * are [[re-entrant]] * do not have internal states * do not require any initialization * are [[synchronous]], i.e. they do not have [[wait point]]s The following libraries are specified: * [[EFx Library|Fixed point mathematical]], * [[BFx Library|Floating point mathematical]], * Interpolation for fixed point data, * Interpolation for floating point data, * Bit handling, * [[E2E Library|E2E communication]], * [[CRC Library|CRC calculation]], * Extended functions (e.g. 64bits calculation, filtering, etc.) and * [[Crypto Abstraction Library|Crypto]] [[IFl Library]] [[MFl Library]] [[MFx Library]] [[IFx Library]] a99ee75af188ff67b48ba49ba9b46c2516c7b15b 0 653 986 2014-08-11T11:34:35Z Oliver 1 Created page with "Wait points are a characteristic of a [[runnable entity]] that specifies that the [[operation system]] blocks the [[runnable]] execution at the specific code position of the [..." wikitext text/x-wiki Wait points are a characteristic of a [[runnable entity]] that specifies that the [[operation system]] blocks the [[runnable]] execution at the specific code position of the [[RTE macro]] until a specific [[RTE Event]] occurs. f99396667675e6967b06032c98169a20287dc5d5 0 654 987 2014-08-11T11:40:42Z Oliver 1 Created page with "[[Integer]], [[Enumeration]], [[Boolean]], etc." wikitext text/x-wiki [[Integer]], [[Enumeration]], [[Boolean]], etc. c009f2414e4bb112e07d16a0035d422bc6e00e49 0 655 990 2014-08-11T21:23:51Z Oliver 1 Created page with "The data access definition defines a [[runnable entity|runnable entities]] read or write access to communication data. A runnable entity can access communication data that is..." wikitext text/x-wiki The data access definition defines a [[runnable entity|runnable entities]] read or write access to communication data. A runnable entity can access communication data that is transferred between [[Software Component]]s via [[Sender-Receiver Interface]] or [[Client-Server Interface]]s. In addition a runnable entity can access [[interrunnable variable]]s that specify data that is transferred between runnable entities of one SW-C. 7cd8a88dbbdc08a21c9e01761c4f22ebe6f9d13a 0 656 993 2014-08-11T21:43:21Z Oliver 1 Redirected page to [[RTE Event#Timing event]] wikitext text/x-wiki #REDIRECT [[RTE Event#Timing event]] 8ab5234b72adb18a495cef71a49ca46c4f46982d 0 657 995 2014-08-11T21:43:54Z Oliver 1 Redirected page to [[RTE Event#Data received event]] wikitext text/x-wiki #REDIRECT [[RTE Event#Data received event]] 0ceb46c5de2a5277d86510360daefb8274a235b6 0 630 998 927 2014-08-11T22:03:59Z Oliver 1 wikitext text/x-wiki Modeling element for specifying communication between the runnable entities in one [[Atomic Software Component]]. 0bc75bb0e769e871180c33427ed558b8fdd5bb56 1000 998 2014-08-11T22:11:17Z Oliver 1 wikitext text/x-wiki Modeling element for specifying communication between the runnable entities in one [[Atomic Software Component]]. An interrunnable variable is a [[variable data prototype]] that requires an [[application data type]] which can have a [[compu method]] and a [[data constraint]] element like the variable data prototype of a [[Sender-Receiver Interface]]. Interrunnable variables can be: * [[Implicit]] which means the runnable entity works on a local copy of an interrunnable variable. A copy of read interrunnable variables is created on entry of the runnable. Changes are written back when the runnable entity completes. This avoids concurrent access to interrunnable variables during runnable entity execution. * [[Explicit]] which means the runnable entity can directly access an interrunnable variable. Changes are immediately visible to other runnable entities with explicit access to the interrunnable variable. 45633e131ed29b5830cf7ee4eb1ce3ab555cddd5 0 659 1003 2014-08-12T12:12:18Z Oliver 1 Redirected page to [[Connector#Assembly Connector]] wikitext text/x-wiki #REDIRECT [[Connector#Assembly Connector]] aa94646d40a0a54eee7d3bb3f174cbca525eae28 0 660 1004 2014-08-12T12:18:19Z Oliver 1 Created page with "[[Application data type]]s have to be mapped to [[Implementation data type]]s before generating the [[RTE]]. For this purpose a data type mapping set has to be defined per S..." wikitext text/x-wiki [[Application data type]]s have to be mapped to [[Implementation data type]]s before generating the [[RTE]]. For this purpose a data type mapping set has to be defined per [[SW-C]] [[internal behavior]]. Also constants that have application data types might need a [[constant specification]] mapping set defined. 75106e364b1c536694650b44b693974072a84c0b 0 164 1009 594 2014-08-13T19:28:04Z 192.168.2.119 0 wikitext text/x-wiki Discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition. An error can arise as a result of unforeseen operating conditions or due to a [[fault]] within the system, [[subsystem]] or [[component]] being considered. A fault can manifest itself as an error within the considered [[element]] and, at the end of its latency, the error can cause a [[failure]]. As errors are faults that have been activated and propagated, a single error can (theoretically) have many possible root causes, i.e., faults. [[fault]] => error => [[failure]]. de3bd4ababf3ee153d04048b50754f1be8881023 0 592 1010 858 2014-08-13T21:03:23Z 192.168.2.119 0 Redirected page to [[Fault Detection Counter]] wikitext text/x-wiki #REDIRECT [[Fault Detection Counter]] e679e2b9351275c8a5e268786ba142075d63a90d 0 661 1011 2014-08-14T21:01:30Z 192.168.2.119 0 Created page with "Event retention is defined as the ability of the [[Dem]] module to record and handle [[event]]s ([[DTC]]s), DTC status information and event related data (e.g. [[freeze frame]..." wikitext text/x-wiki Event retention is defined as the ability of the [[Dem]] module to record and handle [[event]]s ([[DTC]]s), DTC status information and event related data (e.g. [[freeze frame]]s, extended data). 117d8a85dd649f00c47e9947757adfa104c661ec 0 662 1012 2014-08-18T21:52:11Z 192.168.2.119 0 Created page with "The activity state is the status of a [[software component]] being executed. The activity state results from the permission state as a precondition and also physical enable co..." wikitext text/x-wiki The activity state is the status of a [[software component]] being executed. The activity state results from the permission state as a precondition and also physical enable conditions. It is not calculated by the [[FIM]] and not available as a status variable. It could only be derived from local information within a software component. 2632f4b59abea0f62d2e504192a3babf5e4c349d 1019 1012 2014-08-18T21:56:19Z 192.168.2.119 0 wikitext text/x-wiki The activity state is the status of a [[software component]] being executed. The activity state results from the [[permission state]] as a precondition and also physical enable conditions. It is not calculated by the [[FIM]] and not available as a status variable. It could only be derived from local information within a software component. 4ad4621211718413a2dd6e3112593e8304fa5dfb 0 663 1013 2014-08-18T21:52:54Z 192.168.2.119 0 Redirected page to [[End Of Line]] wikitext text/x-wiki #REDIRECT [[End Of Line]] 01b0b003320d311560356b7ff0af462399925b08 0 664 1014 2014-08-18T21:53:16Z 192.168.2.119 0 Redirected page to [[Electro Static Disturbance]] wikitext text/x-wiki #REDIRECT [[Electro Static Disturbance]] 677b734666c3368332fb81b833f99a4e08cad1ce 0 665 1015 2014-08-18T21:53:31Z 192.168.2.119 0 Redirected page to [[Electronic Stability Program]] wikitext text/x-wiki #REDIRECT [[Electronic Stability Program]] 92e307b23d188cbe1e4c0ca673a8c6e546a3fe72 0 666 1016 2014-08-18T21:53:52Z 192.168.2.119 0 Redirected page to [[Function Identifier]] wikitext text/x-wiki #REDIRECT [[Function Identifier]] 07786ccd06a277d288290450b4bb3d58e0ebd76d 0 594 1017 860 2014-08-18T21:54:36Z 192.168.2.119 0 Redirected page to [[In Use Monitoring Performance Ratio]] wikitext text/x-wiki #REDIRECT [[In Use Monitoring Performance Ratio]] 8f0eafb3329c3e9b4a995da2d585652b1cd14503 0 667 1018 2014-08-18T21:55:09Z 192.168.2.119 0 Created page with "The In-Use-Monitor Performance Ratio (IUMPR) indicates how often the [[OBD]] system monitors, particular [[component]]s, compared to the amount of the vehicle operation. It is..." wikitext text/x-wiki The In-Use-Monitor Performance Ratio (IUMPR) indicates how often the [[OBD]] system monitors, particular [[component]]s, compared to the amount of the vehicle operation. It is defined as the number of times a [[fault]] could have been found (=numerator) divided by the number of times the vehicle operation has been fulfilled (=denominator) as defined in the respective OBD regulations. a97ace5a6c8f61d094155fecb9028a4c5efc876c 0 668 1020 2014-08-18T21:56:21Z 192.168.2.119 0 Created page with "The permission state contains the information whether a functionality, represented by its [[FID]], can be executed or whether it shall not run. The state is controlled by the ..." wikitext text/x-wiki The permission state contains the information whether a functionality, represented by its [[FID]], can be executed or whether it shall not run. The state is controlled by the [[FIM]] based on reported [[event]]s. b7b47f552013c13ba6a4828028dd2a1fd2703d4e 0 452 1021 866 2014-08-18T21:59:01Z 192.168.2.119 0 wikitext text/x-wiki The Function Inhibition [[Manager]] (FIM) is a [[Basic Software Module]] of the [[Diagnostic Services]]. The FiM stands for the evaluation and assignment of events to the required actions for [[Software Component]]s (e.g. inhibition of specific “Monitors”). The Function Inhibition Manager is responsible for providing a control mechanism for software components and the functionality therein. In this context, a functionality can be built up of the contents of one, several or parts of [[runnable entity|runnable entities]] with the same set of permission / [[inhibit condition]]s. By means of the FIM, the inhibiting of these functionalities can be configured and even modified by [[calibration]]. Therefore, the adaptation of a functionality into a new system context with modified physical boundary conditions and influences is significantly enhanced. A functionality in the sense of the FIM and a runnable entity are different and independent types of classifications. Runnable entities are mainly featured by their scheduling requirements. In contrast to that, functionalities are classified by their inhibit conditions. The services of the FIM focus on applications in the SW-Cs, however, they are not limited to them. Functionalities of the [[BSW]] can also use the FIM services. Note, there is no functional relationship between [[RTE]] and FIM. The RTE only provides communication in the sense that it connects the required ports of the SW components with the provided [[port]](s) of the FIM. But the RTE does not implement any functionality of the FIM. In contrast to that, the FIM deals with inhibit conditions and provides supporting mechanisms for controlling functionalities within [[runnables]] via respective identifiers ([[FID]]). Therefore, the FIM and RTE concepts do not interfere with each other. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Fim_GetFunctionPermission === [[Standardized Interface]] === Fim_DemTriggerOnEventStatus bc4803bf3b4e090f0ac0145d63a126058c081bde 0 356 1022 416 2014-08-19T11:26:53Z Oliver 1 wikitext text/x-wiki The Virtual Functional Bus is an abstraction of the communication between [[Atomic Software Component]]s and [[AUTOSAR Service]]s. This abstraction is such that specification of the communication mechanisms is independent from the concrete technology chosen to realize the communication. After compilation and linking of software for a dedicated [[ECU]] the Virtual Functional Bus interfaces are realized by the AUTOSAR [[Runtime Environment]]. c9593681f83f326838143ce030b6484cd9f49bda 0 322 1023 376 2014-08-19T12:19:54Z Oliver 1 wikitext text/x-wiki A [[Software Component]] Interface (SW-CI) is the sum of all interfaces offered by the [[Basic Software]], towards the Software Component (SW-C). A SW-CI denotes the interface between an SW-C and the underlying [[Basic Software cluster]] including the [[RTE]]. The SW-CI therefore comprises all [[API]], [[function]]s and [[callback]]s that the SW-C requires from and provides to the Basic Software (generally by means of RTE mechanisms). It includes also the mechanisms allowing SW-Cs sharing the SW-CI to communicate with one another. For the purposes of this definition, the Basic Software clustered on an [[ECU]] can be designed according to [[ICC1]], [[ICC2]] and [[ICC3]]. 25531e2cd3295f014d77d7b6cee8d62f729c2359 0 116 1024 123 2014-08-19T12:21:33Z Oliver 1 wikitext text/x-wiki An AUTOSAR Service is a logical [[entity]] of the basic software ([[BSW]]) offering general functionality to be used by various software components ([[SW-C]]). The functionality is accessed via standardized [[AUTOSAR Interface]]s. Parts of the basic software required to realize AUTOSAR communication patterns and communication attributes are not called [[AUTOSAR Service]]s. 02450a712addf31cf5f6bdca9b601e031c8626b5 1025 1024 2014-08-19T12:21:59Z Oliver 1 wikitext text/x-wiki An AUTOSAR Service is a logical [[entity]] of the basic software ([[BSW]]) offering general functionality to be used by various software components ([[SW-C]]). The functionality is accessed via standardized [[AUTOSAR Interface]]s. Parts of the basic software required to realize AUTOSAR communication patterns and communication attributes are not called AUTOSAR Services. 9aaafb5809a4e5d24ef81b2f9bbbe118629459dc 0 280 1026 328 2014-08-19T21:42:39Z 192.168.2.119 0 wikitext text/x-wiki A private interface is an [[Interface]] within the [[Basic Software]] of AUTOSAR which is neither standardized nor defined within AUTOSAR. The goal of the private interface is to enable a more efficient implementation of basic software modules. [[Basic Software Module]]s sharing a private interface have to be distributed as one package. This package has to behave exactly the same as separate modules would. It must provide the same standardized interfaces to the rest of the Basic Software and/or [[RTE]] as separate modules would. It has to be configured exactly the same as separate modules would be configured. 886b0f8abd889920e27f686fa90b0bdfbb5aa939 0 669 1027 2014-08-19T21:43:40Z 192.168.2.119 0 Created page with "An [[AUTOSAR]] Package is some kind of ‘bundle’ in order to group [[SW-C]]s, [[Data Type]]s and other elements of AUTOSAR. When using [[ARText]] each ARText file must spec..." wikitext text/x-wiki An [[AUTOSAR]] Package is some kind of ‘bundle’ in order to group [[SW-C]]s, [[Data Type]]s and other elements of AUTOSAR. When using [[ARText]] each ARText file must specify a package. 5fa9fdf714b666221b903da3a42a05ab68c26d33 0 670 1028 2014-08-19T21:46:00Z Oliver 1 Created page with "A Data Type is an element that classifies a particular type of information, a set of data having predefined characteristics. The characteristics of a Data Type define the valu..." wikitext text/x-wiki A Data Type is an element that classifies a particular type of information, a set of data having predefined characteristics. The characteristics of a Data Type define the values that a variable can contain. The properties of a Data Type define the values that a variable can contain. = Application Data Type = Application Data Types support the application view of developing [[ECU]] software (resp. the view of [[Software Component]]s). = Implementation Data Type = Implementation Data Types let the [[integrator]] specify the implementation details such as [[Software Base Types]] or [[endianness]]. 9be499bee7d104271bc7fc6411fda458a5ce120a 1040 1028 2014-08-19T21:53:08Z Oliver 1 wikitext text/x-wiki A Data Type is an element that classifies a particular type of information, a set of data having predefined characteristics. The characteristics of a Data Type define the values that a variable can contain. The properties of a Data Type define the values that a variable can contain. = Application Data Type = Application Data Types support the application view of developing [[ECU]] software (resp. the view of [[Software Component]]s). = Implementation Data Type = Implementation Data Types let the [[integrator]] specify the implementation details such as [[Software Base Types]] or [[endianness]]. = Primitive Data Type = [[Integer]], [[Enumeration]], [[Boolean]], etc. 71ca6f749cc4a11574a4d97f875b32e5c68d7440 0 240 1029 961 2014-08-19T21:47:30Z Oliver 1 /* Sender-Receiver Interface */ wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. = Port Interface = Each [[port]] on a [[Software Component]] has to have a port-interface assigned. An interface is attached to a [[port]] and describes the data or [[operation]]s that are provided or required by a [[software component]] via that port. A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[Client-Server communication]] is chosen or a [[Sender-Receiver Interface]] in case [[Sender-Receiver communication]] is used. Further more it can also be a [[Parameter Interface]], [[Non Volatile Data Interface]], [[Trigger Interface]] or [[Mode Switch Interface]]. It defines the contract that must be fulfilled by the port providing or requiring that interface. = Sender-Receiver Interface = A sender-receiver (S/R) interface is a special kind of [[port-interface]] used for the case of [[sender-receiver communication]]. The sender-receiver interface defines the [[data-element]]s which are sent by a sending [[component]] (which has a [[p-port]] providing the sender-receiver interface) or received by a receiving component (which has an [[r-port]] requiring the sender-receiver interface). Sender-Receiver interfaces are used for data exchange between software components. The interface specifies which data is transferred from the sender to the receiver. It is composed of variable data prototypes and specifies the transferred data. The variable data prototypes are of a type which describes the possible values of a variable on physical and internal level. The internal values of the [[Data Type]] can be converted to physical values via a [[compu method]]. The range of the values can be restricted with [[data constr]] elements. = Client-Server Interface = The client-server interface is a special kind of [[port-interface]] used for the case of [[client-server communication]]. The client-server interface defines the operations that are provided (implemented) by the [[server]] and that can be used by the [[client]]. Client-server interfaces allow a client to call an operation at a server, which in turn provides the result to the client. The [argument data prototype]]s of the operation of an interface can be the client input to the server (IN) or the server result (OUT) or both (INOUT). = Types of interfaces within [[Basic Software]] = ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf * page 59 "Components and interfaces view (simplified)".'' * page 60 "General Interfacing Rules" There are three different interfaces defined in: == AUTOSAR Interface == The AUTOSAR Interface of a software component ([[SW-C]]) refers to the collection of all [[port]]s of that component through which it interacts with other components. An AUTOSAR Interface defines the information exchanged between software components and/or [[BSWM|BSW Modules]]. This description is independent of a specific programming language, [[ECU]] or network technology. AUTOSAR Interfaces are used in defining the ports of software-components and/or BSW modules. Through these ports software-components and/or BSW modules can communicate with each other (send or receive information or invoke services). AUTOSAR makes it possible to implement this communication between SW-C and/or BSW modules either locally or via a [[network]]. == Standardized AUTOSAR Interface == This is an AUTOSAR Interface which is standardized within the AUTOSAR project. AUTOSAR [[Service]]s interact with other [[Software Component]]s through a Standardized AUTOSAR Interface. A Standardized AUTOSAR Interface is an [[AUTOSAR Interface]] whose syntax and semantics are standardized in AUTOSAR. The Standardized AUTOSAR Interfaces are typically used to define [[AUTOSAR Service]]s, which are standardized [[service]]s provided by the AUTOSAR [[Basic Software]] to the application Software Components. == Standardized Interface == A software [[interface]] is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[Basic Software]] interact which each other through Standardized Interfaces. A Standardized Interface is an [[API]] which is standardized within AUTOSAR without using the [[AUTOSAR Interface]] technique. These "Standardized Interfaces" are typically defined for a specific programming language (like "C"). Because of this, "standardized interfaces" are typically used between Software Modules which are always on the same [[ECU]]. When software modules communicate through a "standardized interface", it is NOT possible any more to route the communication between the software-modules through a network. 73975fb699c6f862649e73769c7fa6d354550ff2 1066 1029 2014-08-24T20:48:45Z Oliver 1 /* Client-Server Interface */ wikitext text/x-wiki A shared boundary between two [[functional unit]]s defined by various characteristics pertaining to the [[function]]s, [[physical interconnection]]s, signal exchanges, and other characteristics, as appropriate. = Port Interface = Each [[port]] on a [[Software Component]] has to have a port-interface assigned. An interface is attached to a [[port]] and describes the data or [[operation]]s that are provided or required by a [[software component]] via that port. A Port Interface characterizes the information provided or required by a [[port]] of a [[Software Component]]. A Port Interface is either a [[Client-Server Interface]] in case [[Client-Server communication]] is chosen or a [[Sender-Receiver Interface]] in case [[Sender-Receiver communication]] is used. Further more it can also be a [[Parameter Interface]], [[Non Volatile Data Interface]], [[Trigger Interface]] or [[Mode Switch Interface]]. It defines the contract that must be fulfilled by the port providing or requiring that interface. = Sender-Receiver Interface = A sender-receiver (S/R) interface is a special kind of [[port-interface]] used for the case of [[sender-receiver communication]]. The sender-receiver interface defines the [[data-element]]s which are sent by a sending [[component]] (which has a [[p-port]] providing the sender-receiver interface) or received by a receiving component (which has an [[r-port]] requiring the sender-receiver interface). Sender-Receiver interfaces are used for data exchange between software components. The interface specifies which data is transferred from the sender to the receiver. It is composed of variable data prototypes and specifies the transferred data. The variable data prototypes are of a type which describes the possible values of a variable on physical and internal level. The internal values of the [[Data Type]] can be converted to physical values via a [[compu method]]. The range of the values can be restricted with [[data constr]] elements. = Client-Server Interface = The client-server interface is a special kind of [[port-interface]] used for the case of [[Client-Server Communication]]. The client-server interface defines the operations that are provided (implemented) by the [[server]] and that can be used by the [[client]]. Client-server interfaces allow a client to call an operation at a server, which in turn provides the result to the client. The [[argument data prototype]]s of the operation of an interface can be the client input to the server (IN) or the server result (OUT) or both (INOUT). = Types of interfaces within [[Basic Software]] = ''TODO: add picture from AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf * page 59 "Components and interfaces view (simplified)".'' * page 60 "General Interfacing Rules" There are three different interfaces defined in: == AUTOSAR Interface == The AUTOSAR Interface of a software component ([[SW-C]]) refers to the collection of all [[port]]s of that component through which it interacts with other components. An AUTOSAR Interface defines the information exchanged between software components and/or [[BSWM|BSW Modules]]. This description is independent of a specific programming language, [[ECU]] or network technology. AUTOSAR Interfaces are used in defining the ports of software-components and/or BSW modules. Through these ports software-components and/or BSW modules can communicate with each other (send or receive information or invoke services). AUTOSAR makes it possible to implement this communication between SW-C and/or BSW modules either locally or via a [[network]]. == Standardized AUTOSAR Interface == This is an AUTOSAR Interface which is standardized within the AUTOSAR project. AUTOSAR [[Service]]s interact with other [[Software Component]]s through a Standardized AUTOSAR Interface. A Standardized AUTOSAR Interface is an [[AUTOSAR Interface]] whose syntax and semantics are standardized in AUTOSAR. The Standardized AUTOSAR Interfaces are typically used to define [[AUTOSAR Service]]s, which are standardized [[service]]s provided by the AUTOSAR [[Basic Software]] to the application Software Components. == Standardized Interface == A software [[interface]] is called Standardized Interface if a concrete standardized [[API]] exists. Modules in the [[Basic Software]] interact which each other through Standardized Interfaces. A Standardized Interface is an [[API]] which is standardized within AUTOSAR without using the [[AUTOSAR Interface]] technique. These "Standardized Interfaces" are typically defined for a specific programming language (like "C"). Because of this, "standardized interfaces" are typically used between Software Modules which are always on the same [[ECU]]. When software modules communicate through a "standardized interface", it is NOT possible any more to route the communication between the software-modules through a network. a14abe58a23ec87f74c2440df2de8d8b2cb61c16 0 326 1030 917 2014-08-19T21:47:45Z Oliver 1 wikitext text/x-wiki A Software Signal is an asynchronous [[event]] transmitted between one [[process]] and another. A SW Signal is the software implementation of an (control-) information. Additionally it may have attributes (e.g. freshness, [[Data Type]], …). It is exchanged between [[Software Component]]s. d220ae1413347f792d5adc302a0f48c2a76dfae1 0 614 1031 968 2014-08-19T21:47:59Z Oliver 1 wikitext text/x-wiki AUTOSAR defines types and prototypes. This concept allows re-using elements (like [[software component]]s, [[Data Type]]s) several times. E.g. a SW-C type defines the properties of the SW-C together with the [[port]]s, [[internal behavior]] etc. The SW-C prototype is the usage of a SW-C type. The prototype contains all elements and properties of the type plus additional properties such as the shortName. A prototype is referencing a type and reuses it's properties. In analogy to C++ the type would be the class and the prototype the instantiation of this class. d8b119827f28503acb1ca7be5dcbe068900572d5 1044 1031 2014-08-19T22:15:39Z Oliver 1 wikitext text/x-wiki AUTOSAR defines types and prototypes. This concept allows re-using elements (like [[Software Component]]s, [[Data Type]]s) several times. E.g. a SW-C type defines the properties of the SW-C together with the [[port]]s, [[internal behavior]] etc. The SW-C prototype is the usage of a SW-C type. The prototype contains all elements and properties of the type plus additional properties such as the shortName. A prototype is referencing a type and reuses its properties. In analogy to C++ the type would be the class and the prototype the instantiation of this class. 93dd847f38c1816f0f91962a0cd66aaaba7478c3 0 626 1032 963 2014-08-19T21:48:16Z Oliver 1 wikitext text/x-wiki A data constraint is an element that restricts the range of a [[Data Type]]. Data constraints are used in conjunction with [[port]]s and [[interface]]s. By using a data constr element one can also specify a minimum and maximum value to define the range of values for a data type. Data constraints are optional (not mandatory) for [[port interface]]s. You can constrain the [[physical value]]s of a [[Data Type]] with a data constr element. f69fd12e6e79102ce053cf7dbae0caa2095a586b 1033 1032 2014-08-19T21:48:31Z Oliver 1 wikitext text/x-wiki A data constraint is an element that restricts the range of a [[Data Type]]. Data constraints are used in conjunction with [[port]]s and [[interface]]s. By using a data constr element one can also specify a minimum and maximum value to define the range of values for a data type. Data constraints are optional (not mandatory) for [[Port Interface]]s. You can constrain the [[physical value]]s of a [[Data Type]] with a data constr element. 1af47cc656d50802dab879535ba677baca929392 0 643 1034 966 2014-08-19T21:48:53Z Oliver 1 wikitext text/x-wiki Per instance memory is instantiated for each instance (prototype) of an atomic [[software component]] of the [[RTE]]. A [[Data Type]] instance can be accessed only by the corresponding atomic software component instance (prototype). 078904ff4993cb403ce62bf0663eda43c6a4a621 0 671 1035 2014-08-19T21:50:31Z Oliver 1 Redirected page to [[Data type#Application Data Type]] wikitext text/x-wiki #REDIRECT [[data type#Application Data Type]] bb8dd327afb4db92896ef79fa139c6fc2f7624fa 1038 1035 2014-08-19T21:51:26Z Oliver 1 Redirected page to [[Data Type#Application Data Type]] wikitext text/x-wiki #REDIRECT [[Data Type#Application Data Type]] dc40d08b22280c30d59604430728c43222ee425a 0 627 1036 918 2014-08-19T21:50:59Z Oliver 1 Redirected page to [[Data Type#Implementation Data Type]] wikitext text/x-wiki #REDIRECT [[Data Type#Implementation Data Type]] 2af9e34002f5565f72e2127e52aa340ddbac57ee 0 672 1037 2014-08-19T21:51:07Z Oliver 1 Redirected page to [[Data Type#Implementation Data Type]] wikitext text/x-wiki #REDIRECT [[Data Type#Implementation Data Type]] 2af9e34002f5565f72e2127e52aa340ddbac57ee 0 628 1039 919 2014-08-19T21:51:41Z Oliver 1 Redirected page to [[Data Type#Application Data Type]] wikitext text/x-wiki #REDIRECT [[Data Type#Application Data Type]] dc40d08b22280c30d59604430728c43222ee425a 0 673 1041 2014-08-19T21:53:19Z Oliver 1 Redirected page to [[Data Type#Primitive Data Type]] wikitext text/x-wiki #REDIRECT [[Data Type#Primitive Data Type]] 453ba36a89a36abc6174d0c746fd296e369d7318 0 654 1042 987 2014-08-19T21:53:25Z Oliver 1 Redirected page to [[Data Type#Primitive Data Type]] wikitext text/x-wiki #REDIRECT [[Data Type#Primitive Data Type]] 453ba36a89a36abc6174d0c746fd296e369d7318 0 674 1046 2014-08-24T20:28:46Z Oliver 1 Redirected page to [[Communication Specification Declaration]] wikitext text/x-wiki #REDIRECT [[Communication Specification Declaration]] 9b3ee385659cb4bedcd3a292061b285e757e4e8c 0 675 1047 2014-08-24T20:29:00Z Oliver 1 Redirected page to [[Communication Specification Declaration]] wikitext text/x-wiki #REDIRECT [[Communication Specification Declaration]] 9b3ee385659cb4bedcd3a292061b285e757e4e8c 0 676 1048 2014-08-24T20:29:15Z Oliver 1 Redirected page to [[Communication Specification Declaration]] wikitext text/x-wiki #REDIRECT [[Communication Specification Declaration]] 9b3ee385659cb4bedcd3a292061b285e757e4e8c 0 677 1049 2014-08-24T20:30:26Z Oliver 1 Created page with "A [[Port]] can ‘override’ attributes of the [[Port Interface]] and add attributes by defining its communication specification declarations (ComSpec / com spec)." wikitext text/x-wiki A [[Port]] can ‘override’ attributes of the [[Port Interface]] and add attributes by defining its communication specification declarations (ComSpec / com spec). 0515cf72dc17b0e6d0bbb315bb827c28daab4a4a 0 678 1050 2014-08-24T20:31:53Z Oliver 1 Created page with "Application Specific Integrated Circuit" wikitext text/x-wiki Application Specific Integrated Circuit ceda5a5d82ab1bfc01204ee2f9c0c5d55776a204 0 679 1051 2014-08-24T20:32:34Z Oliver 1 Redirected page to [[Behavior Model]] wikitext text/x-wiki #REDIRECT [[Behavior Model]] bf275d0866431a2bfa5af32dccc8222baa351147 0 680 1052 2014-08-24T20:34:03Z Oliver 1 Redirected page to [[Conformance Test Specification]] wikitext text/x-wiki #REDIRECT [[Conformance Test Specification]] c637f280e128b25e943e1a3e63d8fd20aeb032bd 0 681 1053 2014-08-24T20:34:50Z Oliver 1 Redirected page to [[Electric/Electronic]] wikitext text/x-wiki #REDIRECT [[Electric/Electronic]] 34010a94f65d39519158004f5caf2252ce4b57bd 0 337 1054 553 2014-08-24T20:34:59Z Oliver 1 wikitext text/x-wiki Boundary conditions that restrict the Design-Freedom of the (cars [[E/E]]-) [[System]]. The design of [[ECU Network]]s and the distribution of functionalities to [[ECU]]s are limited by several constrains. These constraints result mostly by the [[Communication Matrix]] and safety requirements. fcfec48d54571da0860e2a864f510f41d0cf2044 0 682 1055 2014-08-24T20:36:22Z Oliver 1 Created page with "Elektromagnetische Verträglichkeit. See [[EMC]]." wikitext text/x-wiki Elektromagnetische Verträglichkeit. See [[EMC]]. 43cb62516192bf9be6893251c49bc299eac74e62 0 683 1056 2014-08-24T20:36:48Z Oliver 1 Redirected page to [[Electromagnetic Compatibility]] wikitext text/x-wiki #REDIRECT [[Electromagnetic Compatibility]] 595261205b0b52551ef29bbc79f014a81c4e943a 0 684 1057 2014-08-24T20:37:18Z Oliver 1 Redirected page to [[Hardware Abstraction Layer]] wikitext text/x-wiki #REDIRECT [[Hardware Abstraction Layer]] d3048c2c191e79fd8cc1d5107f01b2de18bce23e 0 685 1058 2014-08-24T20:38:03Z Oliver 1 Redirected page to [[Intellectual Property]] wikitext text/x-wiki #REDIRECT [[Intellectual Property]] b71f1fd82eb4d65b3617976649db31bd6605fc6e 0 686 1059 2014-08-24T20:39:39Z Oliver 1 Created page with "Japan Automotive Software Platform and Architecture. [https://www.jaspar.jp/english/index_e.php]" wikitext text/x-wiki Japan Automotive Software Platform and Architecture. [https://www.jaspar.jp/english/index_e.php] be297a6b1b60add1714eb43f028c7b42c5b81aab 0 74 1060 77 2014-08-24T20:41:05Z Oliver 1 wikitext text/x-wiki [[OSEK]] Implementation Language or Open Issue List f65cad9b845ad7fe70b6a52f404d5235c93aba51 0 687 1061 2014-08-24T20:42:00Z Oliver 1 Created page with "'REDIRECT [[Open System Interconnection]]" wikitext text/x-wiki 'REDIRECT [[Open System Interconnection]] eb94d4db19862e6966c064dffbbbea5f11a9aad2 1065 1061 2014-08-24T20:45:06Z Oliver 1 Redirected page to [[Open System Interconnection]] wikitext text/x-wiki #REDIRECT [[Open System Interconnection]] b37824cf2bf44a4148352412e9705450e55cd632 0 264 1062 306 2014-08-24T20:42:21Z Oliver 1 wikitext text/x-wiki A Network Interface is the sum of all [[interface]]s offered by the [[Basic Software]] towards its connected [[network]]. The interface that the Basic Software shares via the [[communication line]]s with other systems that behave like AUTOSAR ECUs in order to - allow distributed [[SW-C]]s to exchange [[inter-ECU signal]]s and to - operate the communication lines (the network) is called Network Interface. A Network Interface (NWI) denotes the interface between the Basic Software and the [[physical network]] ([[OSI]] Layer 0) to which the ECU executing the Basic Software is connected to (e.g. [[CAN]], [[LIN]], [[FlexRay]]). The NWI therefore transports [[network data packet]]s between the Basic Software and the physical network. The interfaces included within the term NWI are: - [[Logical interface]]s, including o Network Management o Data Management o Data transmission/reception The interfaces excluded from the term NWI are: - The physical network interface (CAN, FlexRay etc.). Note that, while attention must be given to the physical form of the network, since it is not formally specified by AUTOSAR, it cannot be considered a part of the conformance test of an AUTOSAR cluster. The NWI provided by a given ECU supports the transfer of data to and from the ECU, and management of the network. For the purposes of this definition, the Basic Software can be designed according to [[ICC1]], [[ICC2]] or [[ICC3]]. 4b183ed85922a8debfb30cc007ebe897eb40259c 0 688 1063 2014-08-24T20:43:33Z Oliver 1 Created page with "Software Process Improvement and Capability Determination (ISO/IEC 15504)." wikitext text/x-wiki Software Process Improvement and Capability Determination (ISO/IEC 15504). 05ebfd335a91df16c137ffa634bd3ae0f09134bf 0 689 1064 2014-08-24T20:44:37Z Oliver 1 Redirected page to [[Unified Modeling Language]] wikitext text/x-wiki #REDIRECT [[Unified Modeling Language]] fb225477f5fb412612ab027baa395d9a004b76b6 0 690 1067 2014-08-24T20:49:42Z Oliver 1 Redirected page to [[Client-Server Interface]] wikitext text/x-wiki #REDIRECT [[Client-Server Interface]] 74567c4a38b0c74600a1e2dd36b0a7d7c3342559 0 691 1068 2014-08-24T20:49:54Z Oliver 1 Redirected page to [[Client-Server Interface]] wikitext text/x-wiki #REDIRECT [[Client-Server Interface]] 74567c4a38b0c74600a1e2dd36b0a7d7c3342559 0 42 1069 45 2014-08-24T20:51:38Z Oliver 1 wikitext text/x-wiki First In First Out See also '''queued''' property of [[Sender-Receiver Communication]] 5005fd6544fe5dcc6f94408e62d3c65befab9f45 0 692 1070 2014-08-24T20:53:53Z Oliver 1 Created page with "Usually a function which is only implemented without functionality. Only the function call and the interfaces are created. Created stubs have to be filled with life (functiona..." wikitext text/x-wiki Usually a function which is only implemented without functionality. Only the function call and the interfaces are created. Created stubs have to be filled with life (functionality) by the programmer. b44ea87fc39a6637834a137573fcf8cc78e6c25f 0 693 1071 2014-08-27T14:34:35Z Oliver 1 Redirected page to [[Transmission Mode Conditions]] wikitext text/x-wiki #REDIRECT [[Transmission Mode Conditions]] e360477cbf2576b2e1162e5feec4982cd041ea2b 0 31 1072 843 2014-08-27T14:36:47Z Oliver 1 wikitext text/x-wiki The Communication Module (COM) is a [[Basic Software Module]] of the [[Communication Services]]. Main features of the COM module are * Provision of signal oriented data interface for the [[RTE]] * Packing of AUTOSAR signals to [[I-PDU]]s to be transmitted * Unpacking of received I-PDUs and provision of received signals to RTE * [[Routing]] of signals from received I-PDUs into I-PDUs to become transmitted * Routing of signal groups from received I-PDUs into I-PDUs to become transmitted * Communication transmission control (start/ stop of I-PDU groups) * Replications of send requests * Guarantee of minimum distances between transmit I-PDUs * Monitoring of receive signals (signals timeout) * Filter mechanisms for incoming signals * Different notification mechanisms * Provision of init values and update indications * [[Byte order]] conversion * Sign extension * Support of two different transmission modes per I-PDU * Signal based gateway * Support of large and dynamic length data types * Support of I-PDU counters and I-PDU replication The AUTOSAR COM module provides the following ComFilterAlgorithms: * ALWAYS * NEVER * MASKED_NEW_EQUALS_X * MASKED_NEW_DIFFERS_X * MASKED_NEW_DIFFERS_MASKED_OLD * NEW_IS_WITHIN * NEW_IS_OUTSIDE * ONE_EVERY_N === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === a4937d95f634d6078807c198a35f67318113e744 0 694 1073 2014-08-27T14:36:58Z Oliver 1 Created page with "Transmission Mode Conditions is used inside the [[COM]] module." wikitext text/x-wiki Transmission Mode Conditions is used inside the [[COM]] module. da9f3df6b9719fac4f571126f13af1408235733c 0 695 1074 2014-09-08T06:21:00Z Oliver 1 Created page with "Modularer Infotainment Baukasten from Volkswagen/Audi." wikitext text/x-wiki Modularer Infotainment Baukasten from Volkswagen/Audi. 03c4c9f8c7b2d5e76b020564819361d15f602aa5 1075 1074 2014-09-08T06:21:26Z Oliver 1 wikitext text/x-wiki Modularer Infotainment Baukasten is a platform from Volkswagen/Audi. dd7294cf7ddf0f0b2279d44af5d8fe64628d980f 0 696 1076 2014-09-08T06:22:22Z Oliver 1 Created page with "Modularer Längs-Baukasten is a platform from Volkswagen." wikitext text/x-wiki Modularer Längs-Baukasten is a platform from Volkswagen. 25b28e0f8f5a8ea72185dff9665e3ef7b87aaf56 0 697 1077 2014-09-08T06:22:37Z Oliver 1 Created page with "Modularer Quer-Baukasten is a platform from Volkswagen." wikitext text/x-wiki Modularer Quer-Baukasten is a platform from Volkswagen. d2b3a9bdeb12518b1b4cbc4b47f4568e52140808 0 25 1078 27 2014-09-08T06:28:23Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] AUTomotive Open System Architecture [http://www.autosar.org] c568d1c2911ac0b118c12cf09d4f22282355c055 0 695 1079 1075 2014-09-08T06:55:30Z Oliver 1 wikitext text/x-wiki Modularer Infotainment Baukasten is a platform from Volkswagen/Audi. Timeframe<ref>Elektronik automotive 8/9.2014 p.33</ref>: *2012 - MIB1 (4,000 DMIPS) *2014 - MIB2 (8,000 DMIPS) *2015 - MIB2 (12,000 DMIPS) *2016 - MIB2+ (20,000 DMIPS) <references /> 5952773739719b3889f53acf0a84c4a5f677fc4e 0 19 1080 650 2014-09-08T21:48:45Z Oliver 1 wikitext text/x-wiki [[Category:hardware]] Analog Digital Converter see also [[ADC Driver]] 4bf2a7d2770050cddc9c066744b3fc243c26b150 0 540 1081 794 2014-09-08T21:49:00Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The ADC [[Driver]] (Adc) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 96c03d2d3b708327fd6dc971b61edeceeadcfeff 0 20 1082 22 2014-09-08T21:49:22Z Oliver 1 Redirected page to [[Application Mode Management]] wikitext text/x-wiki #REDIRECT [[Application Mode Management]] d7adfd25b4d54d67a75af534249967ac871a1f63 0 21 1083 108 2014-09-08T21:49:41Z Oliver 1 wikitext text/x-wiki [[Category:software]] An Application Programming Interface (API) is the prescribed method of a specific software part by which a programmer writing a program can make requests to that software part. It precisely defines the interfaces with all it's parameters. 52c80e91b6b9ae1544851b530f2cd97215b1a23e 0 22 1084 24 2014-09-08T21:50:13Z Oliver 1 Redirected page to [[Address Resolution Protocol]] wikitext text/x-wiki #REDIRECT [[Address Resolution Protocol]] cea3b64d0372e9df3376f149e0dd978e78044629 0 678 1085 1050 2014-09-08T21:50:36Z Oliver 1 wikitext text/x-wiki [[Category:hardware]] Application Specific Integrated Circuit 69362caea77dca6fc6b2c44971f4775b061b1f15 0 113 1086 119 2014-09-08T21:51:24Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[AUTOSAR]] metamodel is a [[UML]]2.0 model that defines the language for describing [[AUTOSAR system]]s and related [[artifact]]s. It is a graphical representation of a [[template]]. UML2.0 class diagrams are used to describe the [[attribute]]s and their [[interrelationship]]s. [[Stereotype]]s and [[OCL]] (object constraint language) are used for defining specific [[semantic]]s and constraints. bdd54ffbb51ab8c2a3312e088b8189ee79b6072c 0 114 1087 120 2014-09-08T21:51:42Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] This is a representation of an [[AUTOSAR product]]. The [[AUTOSAR]] model represents aspects suitable to the intended use according to the [[AUTOSAR methodology]]. Strictly speaking, this is an instance of the [[AUTOSAR metamodel]]. The information contained in the AUTOSAR model can be anything that is representable according to the AUTOSAR metamodel. c173293b7e93fb8b6d2f43e9c9887735d1f7766b 0 115 1088 312 2014-09-08T21:51:55Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] In AUTOSAR, the possible [[partitioning]] of models is marked in the [[meta-model]] by <<atpSplitable>>. One partial model is represented in an [[AUTOSAR XML description]] by one file. The partial model does not need to fulfill all semantic constraints applicable to an [[AUTOSAR model]]. c9afb3597b40bd6d1a719ddbdb00cc50b83b1210 0 116 1089 1025 2014-09-08T21:52:06Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] An AUTOSAR Service is a logical [[entity]] of the basic software ([[BSW]]) offering general functionality to be used by various software components ([[SW-C]]). The functionality is accessed via standardized [[AUTOSAR Interface]]s. Parts of the basic software required to realize AUTOSAR communication patterns and communication attributes are not called AUTOSAR Services. 7790ac014883df3cc2a16d75ceb6c748dd0c7022 0 117 1090 126 2014-09-08T21:53:00Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] This is a software tool which supports one or more [[task]]s defined as AUTOSAR tasks in the [[AUTOSAR methodology]]. Depending on the supported tasks, an [[AUTOSAR tool]] can act as an [[AUTOSAR authoring tool]], a [[AUTOSAR converter tool]], a [[AUTOSAR processor tool]] or as a combination of those. 330a502f99fa5c6a37f47c73c4cabbe52f3f3864 0 119 1091 127 2014-09-08T21:53:21Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[AUTOSAR]] XML Schema is an [[XML]] language definition for exchanging [[AUTOSAR model]]s and descriptions. It is a W3C XML schema that defines the language for exchanging AUTOSAR models. This Schema is derived from the [[AUTOSAR metamodel]]. The AUTOSAR XML Schema defines the AUTOSAR data exchange format. 08a5bda734c9336b3adf7fa0c5de61106726f094 0 118 1092 125 2014-09-08T21:53:40Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] In [[AUTOSAR]] this means "Filled Template". In fact an AUTOSAR XML description is the [[XML]] representation of an [[AUTOSAR model]]. The AUTOSAR XML description can consist of several files. Each individual file represents an [[AUTOSAR partial model]] and must validate successfully against the [[AUTOSAR XML schema]]. 9f9c616125cca96d93c52f59d1badebe86c5fe35 0 101 1093 104 2014-09-08T21:54:03Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Third-party]] attestation to an organization conveying formal demonstration of its competence to carry out [[AUTOSAR conformance]] test tasks. Within the AUTOSAR environment two different scopes of accreditation exist: - In reference to ISO/IEC 17025 for accreditation of organizations performing conformance testing within own laboratories. - In reference to ISO/IEC Guide 65 for accreditation of [[Conformance Test Agencies]] ([[CTA]]) performing 3rd party product conformance attestation. afe6f8e8c13ae3faabbd8e8990e42916226fc3a1 0 102 1094 498 2014-09-08T21:54:21Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] This is an organization, which employs or contracts individual [[assessor]]s, who in turn perform the [[independent assessment]]s as part of the [[accreditation]] process. In the [[AUTOSAR]] context the Accreditation Bodies have the [[role]] to accredit the [[Conformance Test Agencies]]. 7388b720eb2de5f7e79a6007f1ef3c5ed3084179 0 406 1095 511 2014-09-08T21:54:43Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] In the [[SPEM meta model]], an Activity is the main building block to define a [[process]]. An Activity is usually a defined [[task]] or work to be done that is commonly executed in one sequence. Activities can include other Activities and thereby often decompose a flow of work and show which Activity precedes other Activities. At the lowest level, Activities are collections of work breakdown elements which in [[AUTOSAR Methodology]] are [[task]]s , [[role]]s , and [[work product]]s. A Process is a special Activity in the SPEM meta model that describes a typical structure of development projects or parts of them. A Process focuses on the lifecycle and the sequencing of work in [[breakdown structure]]s. [[Process]]es contain sequences of Task and Activities and thereby express a [[lifecycle]] of the product under development. Processes also define how to get from one [[milestone]] to the next by defining sequences of work, [[operation]]s, or [[event]]s. 59732abe2fdc575f38a2de398235ef0937379c3f 0 662 1096 1019 2014-09-08T21:55:34Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] The activity state is the status of a [[software component]] being executed. The activity state results from the [[permission state]] as a precondition and also physical enable conditions. It is not calculated by the [[FIM]] and not available as a status variable. It could only be derived from local information within a software component. 627e403605154430f99dc4d3cbc2399ca58de2b7 0 10 1097 12 2014-09-08T21:55:51Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The “Administrative Block” is a [[Basic Storage Object]]. It resides in [[RAM]]. The “Administrative Block” is a mandatory part of a [[NVRAM Block]]. 3e9844a59811d39c142a9deef78eed93c9c5bc09 0 587 1098 882 2014-09-08T21:56:18Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Unlearning/deleting of a no longer failed event/[[DTC]] after a defined number of [[operation cycle]]s from [[event memory]]. The [[Dem]] module provides the ability to remove a specific event from the event memory, if its fault conditions are not fulfilled for a certain period of time (operation cycles). This process is called as “aging” or “unlearning”. 06c95ca72accead55d868ad15ee75bbd94dffc17 0 103 1099 107 2014-09-08T21:56:58Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] 1. A software (or program) that is specified to the solution of a problem of an end user requiring information processing for its solution. In [[AUTOSAR]] Application software is located above the AUTOSAR [[RTE]]. 2. The [[software configuration]] of a [[software entity]]. Definition 1 is the “by default” meaning for application in AUTOSAR. When definition 2 is meant, it has to be explicitly mentioned. f6edd31a5376b533ba367f690ab6bf19dc0d4e86 0 450 1100 585 2014-09-08T21:57:19Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Application Layer is the layer above the [[RTE]] where all [[Software Component]]s are 'located'. 9778184f8b9020728321d736fd974f8535459879 0 104 1101 906 2014-09-08T21:58:10Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] An Application Software Component is a specific [[Software Component]] which realizes a defined functionality on application level (above the [[RTE]]) and runs on the [[AUTOSAR]] infrastructure. It communicates only through the AUTOSAR Runtime Environment (RTE). The Application Software Component is an [[Atomic Software Component]] that implements (part of) an [[application]]. It can use all [[AUTOSAR communication mechanism]]s and [[service]]s. It interacts with [[sensor]]s or [[actuator]]s through a [[Sensor-Actuator Software Component]]. The Application Software Component is an [[Atomic Software Component]] that is hardware independent. 18604e8b9b41da79f3c0f9c44becf83913d34fe7 0 106 1102 496 2014-09-08T21:58:52Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] This is a [[Work Product]] Definition that provides a description and definition for tangible work product types. Artifacts may be composed of other artifacts. At a high level, an artifact is represented as a single conceptual file. A tangible [[Work Product]] that is consumed, produced, or modified by one or more [[Task]]s. Artifacts may be composed of other Artifacts and may serve as a basis for defining reusable asset. For the [[AUTOSAR Methodology]], typical kinds of artifacts are: – AUTOSAR XML – source code – binary code (executable) – text At a high level, an artifact is represented as a single conceptual file. As a rule of thumb, the [[AUTOSAR]] Methodology will use artifacts that have most of the following properties: – Separate versioning is needed – A dedicated [[life cycle]] has to be cared for – Different exchange requirements need to be fulfilled – Change in responsible [[role]]s – Change in multiplicities – Change is physical representation or format – One of the products may be a separate deliverable to another party – Separation of standardized from non-standardized parts To express a relationship between artifacts of the methodology model and any [[AUTOSAR metamodel]] element, a relationship with the stereotype «atpUseMetaModelElement» is used to express this ”dependency”. For AUTOSAR metamodel elements that are not directly related to methodology elements, there is usually an indirect relationship via a related metamodel element. The methodology can thus focus on the main elements of the metamodel. 46162835715f44eaa56c063fc0da1b5cd13d24a4 1103 1102 2014-09-08T21:59:13Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] This is a [[Work Product]] Definition that provides a description and definition for tangible work product types. Artifacts may be composed of other artifacts. At a high level, an artifact is represented as a single conceptual file. A tangible [[Work Product]] that is consumed, produced, or modified by one or more [[Task]]s. Artifacts may be composed of other Artifacts and may serve as a basis for defining reusable asset. For the [[AUTOSAR Methodology]], typical kinds of artifacts are: – AUTOSAR XML – source code – binary code (executable) – text At a high level, an artifact is represented as a single conceptual file. As a rule of thumb, the [[AUTOSAR]] Methodology will use artifacts that have most of the following properties: – Separate versioning is needed – A dedicated [[life cycle]] has to be cared for – Different exchange requirements need to be fulfilled – Change in responsible [[role]]s – Change in multiplicities – Change is physical representation or format – One of the products may be a separate deliverable to another party – Separation of standardized from non-standardized parts To express a relationship between artifacts of the methodology model and any [[AUTOSAR Metamodel]] element, a relationship with the stereotype «atpUseMetaModelElement» is used to express this ”dependency”. For AUTOSAR metamodel elements that are not directly related to methodology elements, there is usually an indirect relationship via a related metamodel element. The methodology can thus focus on the main elements of the metamodel. 29abbf317732e8d76af0f8f37084484ebd06018c 0 107 1104 510 2014-09-08T21:59:44Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Activity]] conducted by an [[assessor]] to demonstrate that the assessed organization fulfills the set requirements. Within the [[AUTOSAR]] context after the initial assessment a new full-set assessment will be repeated every 4 years. In between, [[surveillances]] take place once a year. 70cbf3fd4af9f2d107fbe1375c907ff98ed3b0c6 0 109 1105 114 2014-09-08T22:01:18Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Asynchronous communication does not block the sending [[software entity]] (like a [[Runnable entity]]). The sending software entity continues its operation without getting a response from the communication partner(s). There could be an acknowledgement by the communication system about the sending of the information. A later response to the sending software entity is possible. 90e3f5adb1582e70d42408e8c23978141c27dff8 0 386 1106 473 2014-09-08T22:02:02Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] An atomic [[Software Component]] cannot be further decomposed into smaller Software Components. 7debe05f466731f6954e40c9228f639b0ff2219b 1107 1106 2014-09-08T22:02:56Z Oliver 1 Redirected page to [[Atomic Software Component]] wikitext text/x-wiki #REDIRECT [[Atomic Software Component]] e557637ebe3a3a2aeb0e348e9fa9b1b0842f87ab 0 111 1108 999 2014-09-08T22:03:44Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Non-composed [[Software Component]] (SW-C). An Atomic Software Component might access [[HW]] or not, therefore not all Atomic SW-Cs are re-locatable. Any [[Software Component]] that can contain a SW-C [[internal behavior]]. An Atomic Software Component communicates with the outside via the [[interface]]s at the SW-C [[port]]s. Interrunnable communication is used for communication between runnables of the same SW-C. The [[runnable entity|runnable entities]] have access to the same [[interrunnable variable]]. An [[Atomic Software Component]] cannot be further decomposed into smaller Software Components. 3a5bb000251234a7a1e1f5ea869ff39059dd8aa1 0 120 1109 128 2014-09-08T22:05:06Z Oliver 1 wikitext text/x-wiki # Probability that a system or [[functional unit]] is able to perform its normal operation under specified conditions at a specific time. # The property of data or resources being accessible and usable on demand by an authorized entity. The time can be used to model a decrease of the availability over time due to e.g. aging of [[component]]s. cbb55439b43d1b01f375783dccd41dd0fe4f8aac 0 698 1110 2014-09-09T06:17:56Z Oliver 1 Redirected page to [[Electronic Control Unit]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit]] 36e857917fdce8ea1b3a7e8262deb830a9919664 0 699 1111 2014-09-09T06:18:09Z Oliver 1 Redirected page to [[Electronic Control Unit]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit]] 36e857917fdce8ea1b3a7e8262deb830a9919664 0 665 1112 1015 2014-09-09T06:18:34Z Oliver 1 Redirected page to [[Electronic Control Unit]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit]] 36e857917fdce8ea1b3a7e8262deb830a9919664 0 159 1113 178 2014-09-09T06:18:47Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ESP || Electronic Stability Program ||Elektronisches Stabilitätsprogramm |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 4a498b3c9d8a184651ed4df98e676c5043997ff7 0 700 1114 2014-09-11T20:42:03Z Oliver 1 Redirected page to [[Adaptive Cruise Control]] wikitext text/x-wiki #REDIRECT [[Adaptive Cruise Control]] d2a8317efb0e4ffbfe27dd2eccd4304f6f2f7b6b 0 701 1115 2014-09-11T20:42:28Z Oliver 1 Redirected page to [[Elektronische Bremskraftverteilung]] wikitext text/x-wiki #REDIRECT [[Elektronische Bremskraftverteilung]] 5db3eaeb7d0ed0434a8a79150e69b810c90fea06 0 702 1116 2014-09-11T20:42:57Z Oliver 1 Redirected page to [[Anti-Schlupfregelung]] wikitext text/x-wiki #REDIRECT [[Anti-Schlupfregelung]] 55fc68e10bb84adeb2b66a704f4905140f60cc92 0 703 1117 2014-09-11T20:43:40Z Oliver 1 Redirected page to [[Capability Maturity Model Integration]] wikitext text/x-wiki #REDIRECT [[Capability Maturity Model Integration]] 29ef884b7363ff594d9def4e16a73a784df10d89 0 704 1118 2014-09-11T20:44:41Z Oliver 1 Created page with "Capability Maturity Model Integration. See [https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration]" wikitext text/x-wiki Capability Maturity Model Integration. See [https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration] 10fb1c4b0952ffe7153f45d30894dfdd45112889 0 688 1119 1063 2014-09-11T20:45:43Z Oliver 1 wikitext text/x-wiki Software Process Improvement and Capability Determination (ISO/IEC 15504). See [https://en.wikipedia.org/wiki/ISO/IEC_15504] 258cc1ede898909809f1d3227335438c6dbf3730 0 705 1120 2014-09-11T20:46:07Z Oliver 1 Redirected page to [[Active Front Steering]] wikitext text/x-wiki #REDIRECT [[Active Front Steering]] d856087c6d2521404ff4d82840ed0dc937fea53b 0 706 1121 2014-09-11T20:48:13Z Oliver 1 Created page with "The Yellowboard is a test bench with real electronic (like wiring, [[ECU]]s, etc.) but without real car like chassis etc." wikitext text/x-wiki The Yellowboard is a test bench with real electronic (like wiring, [[ECU]]s, etc.) but without real car like chassis etc. 0d0fd53e94c131bc3e25ae954fdd639c538583f5 0 707 1122 2014-09-11T20:48:40Z Oliver 1 Redirected page to [[Yellowboard]] wikitext text/x-wiki #REDIRECT [[Yellowboard]] c8845a45e9296f4b1a6a4b7dddd3d90fe46bca2a 0 358 1123 420 2014-09-11T20:49:28Z Oliver 1 wikitext text/x-wiki Maximum possible time during which a program is actually executing. The worst case [[execution time]] of a piece of software is the maximum possible time during which the [[CPU]] is executing instructions which belong to this piece. The worst case execution time is often identified by analytical methods. It is required to determine if a schedule meets the overall timing requirements. Abbreviation: WCET See also: [[response time]], [[execution time]], [[worst case response time]] c9c839de0f1d760f25e2794cc9706b61ee46afe7 0 708 1124 2014-09-11T20:50:28Z Oliver 1 Redirected page to [[Mean Time to Failure]] wikitext text/x-wiki #REDIRECT [[Mean Time to Failure]] b6b8b84aaee6df76ef822454ee8696679f308a36 0 595 1125 861 2014-09-11T20:50:50Z Oliver 1 Redirected page to [[Malfunction Indication Light]] wikitext text/x-wiki #REDIRECT [[Malfunction Indication Light]] 5bb870d2318ed09313c964077c9d79c1e267197e 0 709 1126 2014-09-11T20:56:19Z Oliver 1 Created page with ""The bordnet is a power supply from hell."" wikitext text/x-wiki "The bordnet is a power supply from hell." 39e309b0ba3fc0fa822b8d1a6929be9dc3bfd8a2 0 710 1127 2014-09-11T21:32:03Z Oliver 1 Created page with "European [[On-Board-Diagnostic]] (OBD)" wikitext text/x-wiki European [[On-Board-Diagnostic]] (OBD) f567a4d1231e6d7cfb28c6ce322f2b6e7db70a00 0 711 1128 2014-09-11T21:32:39Z Oliver 1 Redirected page to [[Field Bus Exchange Format]] wikitext text/x-wiki #REDIRECT [[Field Bus Exchange Format]] 4dbeae1f70133cb57a73c96b8e818e00b7ccac91 0 426 1129 547 2014-09-11T21:32:52Z Oliver 1 wikitext text/x-wiki The communication matrix is defining the [[message]]s/[[signal]] sent and received by each participating [[node]]. It could be defined in a [[FIBEX]]-file ([[FlexRay]]), CANdb-file ([[CAN]]) or AUTOSAR [[arxml]]-file. d14aaf211809acb4bbc57488997e301836d1c5eb 0 63 1130 66 2014-09-11T21:33:25Z Oliver 1 Redirected page to [[Human Machine Interface]] wikitext text/x-wiki #REDIRECT [[Human Machine Interface]] b255059591f96b725a6228b31b9d451a669cc23d 0 48 1131 51 2014-09-11T21:34:00Z Oliver 1 Redirected page to [[Implementation Conformance Class]] wikitext text/x-wiki #REDIRECT [[Implementation Conformance Class]] c1badb71ad2f388fc37dbb253e6ae796a7142927 0 596 1132 862 2014-09-11T21:35:21Z Oliver 1 Redirected page to [[Onboard Diagnostics]] wikitext text/x-wiki #REDIRECT [[Onboard Diagnostics]] 037738512914619f5941336a2af7ccd09b73c045 1140 1132 2014-09-11T21:42:01Z Oliver 1 Redirected page to [[Onboard Diagnostic]] wikitext text/x-wiki #REDIRECT [[Onboard Diagnostic]] cbdf1be4cc5aff630477df20a2b581523a0b50ce 0 710 1133 1127 2014-09-11T21:36:00Z Oliver 1 wikitext text/x-wiki European [[Onboard Diagnostics]] (OBD) 293e0a3b78d2119309dd62eff37efb07f7babe23 1137 1133 2014-09-11T21:39:36Z Oliver 1 Redirected page to [[Onboard Diagnostic]] wikitext text/x-wiki #REDIRECT [[Onboard Diagnostic]] cbdf1be4cc5aff630477df20a2b581523a0b50ce 0 712 1134 2014-09-11T21:36:37Z Oliver 1 Created page with "US [[Onboard Diagnostics]] (OBD)" wikitext text/x-wiki US [[Onboard Diagnostics]] (OBD) 3e244503534e613ce5506a38332345d986edd5db 1135 1134 2014-09-11T21:38:12Z Oliver 1 Redirected page to [[Onboard Diagnostics]] wikitext text/x-wiki #REDIRECT [[Onboard Diagnostics]] 037738512914619f5941336a2af7ccd09b73c045 1136 1135 2014-09-11T21:38:45Z Oliver 1 Redirected page to [[Onboard Diagnostic]] wikitext text/x-wiki #REDIRECT [[Onboard Diagnostic]] cbdf1be4cc5aff630477df20a2b581523a0b50ce 0 713 1138 2014-09-11T21:40:37Z Oliver 1 Redirected page to [[Onboard Diagnostic]] wikitext text/x-wiki #REDIRECT [[Onboard Diagnostic]] cbdf1be4cc5aff630477df20a2b581523a0b50ce 0 714 1139 2014-09-11T21:40:52Z Oliver 1 Created page with "*OBDII: US Onboard Diagnostics *EOBD: European Onboard Diagnostics *JOBD: Japanese Onboard Diagnostics" wikitext text/x-wiki *OBDII: US Onboard Diagnostics *EOBD: European Onboard Diagnostics *JOBD: Japanese Onboard Diagnostics 410a50b1e071f81e857a7cee69115e3d8c0fd9e0 1141 1139 2014-09-11T21:42:19Z Oliver 1 wikitext text/x-wiki *OBD: Onboard Diagnostics *OBDII: US Onboard Diagnostics *EOBD: European Onboard Diagnostics *JOBD: Japanese Onboard Diagnostics f18b3d7463587e7ccb857006455f0355c71129cc 0 715 1142 2014-09-11T21:44:11Z Oliver 1 Redirected page to [[Testing and Test Control Notation]] wikitext text/x-wiki #REDIRECT [[Testing and Test Control Notation]] cb173c50ba16ac6ae3990d92121f334467564ac0 0 716 1143 2014-09-11T21:44:48Z Oliver 1 Created page with "Audio Video Bridging (IEEE 802.1)" wikitext text/x-wiki Audio Video Bridging (IEEE 802.1) 97e6fd348fe65537229701da9082240315148a90 0 717 1144 2014-09-11T21:47:21Z Oliver 1 Created page with "Institute of Electrical and Electronics Engineers. See [https://www.ieee.org/index.html]" wikitext text/x-wiki Institute of Electrical and Electronics Engineers. See [https://www.ieee.org/index.html] f0c6879818c881bd9fabbc268da32ca9724f6825 0 685 1145 1058 2014-09-11T21:48:07Z Oliver 1 wikitext text/x-wiki *[[Intellectual Property]] *[[Internet Protocol]] 35911070332b0e4d72e1ac69e1911ca574c77ae6 0 718 1146 2014-09-11T21:49:18Z Oliver 1 Created page with "Kraftfahrzeug" wikitext text/x-wiki Kraftfahrzeug b73aaeaf17cf7a06712e313e6303d9afc3cd6071 0 719 1147 2014-09-11T21:50:02Z Oliver 1 Created page with "Low Voltage Differential Signaling" wikitext text/x-wiki Low Voltage Differential Signaling 1198ca847976b99d1715f2c2a27956138e5673c8 0 720 1148 2014-09-11T21:50:24Z Oliver 1 Created page with "Open Diagnostic Data Exchange" wikitext text/x-wiki Open Diagnostic Data Exchange 63e5d873729f420374a2ff2ce33f660b2e3339d3 0 721 1149 2014-09-11T21:51:37Z Oliver 1 Created page with "Open DeviceNet Vendor Association. See [http://www.odva.org/]" wikitext text/x-wiki Open DeviceNet Vendor Association. See [http://www.odva.org/] 42227a238323510a24c484bd51cd6af40b790d99 0 722 1150 2014-09-11T21:52:48Z Oliver 1 Created page with "Personal Computer" wikitext text/x-wiki Personal Computer b36efdfad52188e5b019d796dbca7ed4da07b2f9 0 723 1151 2014-09-11T21:52:52Z Oliver 1 Created page with "Personenkraftwagen" wikitext text/x-wiki Personenkraftwagen de060fdf2eabbf504576d5b4b14c37e9029b37fa 0 724 1152 2014-09-11T21:54:12Z Oliver 1 Created page with "Quality of Service" wikitext text/x-wiki Quality of Service 32ec61629943ed1868006efc472e665986de9aa9 0 98 1153 101 2014-09-11T21:54:41Z Oliver 1 wikitext text/x-wiki Universal Calibration Protocol as the extension of [[CCP]]. 35d04c96e10b206e9f9aa4d5efbb9efc77718b67 0 725 1154 2014-09-11T21:55:16Z Oliver 1 Created page with "Defines the limits of variance in function performance of the device during exposure to an electromagnetic disturbance." wikitext text/x-wiki Defines the limits of variance in function performance of the device during exposure to an electromagnetic disturbance. 0105b925b74b9aaa9d4f4221830d2bfbe4958fc4 1173 1154 2014-09-11T22:06:06Z Oliver 1 wikitext text/x-wiki Defines the limits of variance in function performance of the device during exposure to an [[electromagnetic disturbance]]. d44a8ee37379a370fd4bed1fda5072dc025015e4 0 726 1155 2014-09-11T21:55:54Z Oliver 1 Created page with "Electronic modules that function via use of digital or analog circuitry including [[microprocessor]]s, operational amplifiers, and memory devices." wikitext text/x-wiki Electronic modules that function via use of digital or analog circuitry including [[microprocessor]]s, operational amplifiers, and memory devices. 6c7f88c8a5c685b90ebe35957dea6dd9d3ad2553 0 727 1156 2014-09-11T21:56:44Z Oliver 1 Created page with "Automotive [[EMC]] Laboratory Recognition Program." wikitext text/x-wiki Automotive [[EMC]] Laboratory Recognition Program. a1ab891021c3de6087add55edde67b34a2eb676c 0 728 1157 2014-09-11T21:57:05Z Oliver 1 Created page with "Absorber-lined shielded enclosure. Also used in this document together with [[ISO]] or [[SAE]] to designate the test itself with reference to the method described in ISO 114..." wikitext text/x-wiki Absorber-lined shielded enclosure. Also used in this document together with [[ISO]] or [[SAE]] to designate the test itself with reference to the method described in [[ISO 11452-1]] or [[SAE J1113-21]]. b7fac471f57294fd5268356dc8f935e8dbaa628d 0 729 1158 2014-09-11T21:58:34Z Oliver 1 Created page with "Supplementary material attached to the end of a [[specification]], often used to supply additional information that may be normative or informative in nature." wikitext text/x-wiki Supplementary material attached to the end of a [[specification]], often used to supply additional information that may be normative or informative in nature. ce11bbf11f784eeeeef49c676230a6d1889b1088 0 730 1159 2014-09-11T21:58:49Z Oliver 1 Redirected page to [[Artificial Network]] wikitext text/x-wiki #REDIRECT [[Artificial Network]] 2f52d091dbcd334aa6d10a9fb7e045144a56460d 0 731 1160 2014-09-11T22:00:01Z Oliver 1 Created page with "A device used to present a known impedance to the power line of the device under test ([[DUT]])." wikitext text/x-wiki A device used to present a known impedance to the power line of the device under test ([[DUT]]). 099ad031979021d602875d057c9524264e9c3b3d 0 732 1161 2014-09-11T22:00:39Z Oliver 1 Created page with "Bulk Current Injection. Method for coupling common mode RF current into a harness." wikitext text/x-wiki Bulk Current Injection. Method for coupling common mode RF current into a harness. 92baa6b71cf03d80d8b3868ac429136e69229d97 0 733 1162 2014-09-11T22:01:18Z Oliver 1 Redirected page to [[Average Detection]] wikitext text/x-wiki #REDIRECT [[Average Detection]] ab2b3c020185182da1affe439b58d40a3bed93fd 0 734 1163 2014-09-11T22:01:37Z Oliver 1 Created page with "A detection method that produces an output voltage of which is the average value of the envelope of an applied signal. The average value must be taken over a specified time in..." wikitext text/x-wiki A detection method that produces an output voltage of which is the average value of the envelope of an applied signal. The average value must be taken over a specified time interval. b49d1dc7a0b4249fb6e7f5e604d0ecf45176846b 0 735 1164 2014-09-11T22:01:57Z Oliver 1 Created page with "Common Mode [[BCI]]." wikitext text/x-wiki Common Mode [[BCI]]. 8cb5ebd87c75b7e1fcf465c927310f8e29977628 0 736 1165 2014-09-11T22:02:33Z Oliver 1 Redirected page to [[Conducted Emissions]] wikitext text/x-wiki #REDIRECT [[Conducted Emissions]] 9367ab6408d6b2aa158748e9e6a7f3174d97c3a2 0 737 1166 2014-09-11T22:02:48Z Oliver 1 Redirected page to [[Conducted Immunity]] wikitext text/x-wiki #REDIRECT [[Conducted Immunity]] c80610e6b093f16774572cf81480825fcd947ef5 0 738 1167 2014-09-11T22:03:17Z Oliver 1 Created page with "“Comité International Spécial des Perturbations Radioeléctriques” (Special International Committee on Radio Interference)." wikitext text/x-wiki “Comité International Spécial des Perturbations Radioeléctriques” (Special International Committee on Radio Interference). 5f2d18b14b56ccc7c85b531aa6dba23bb4e0a18a 0 739 1168 2014-09-11T22:03:45Z Oliver 1 Redirected page to [[Centralized Load Dump]] wikitext text/x-wiki #REDIRECT [[Centralized Load Dump]] 368b498ea15e2aafad645993d51a5951878b26f3 0 740 1169 2014-09-11T22:04:12Z Oliver 1 Created page with "I/O circuits that are connected to the vehicle battery via switches, relays or resistive/inductive loads, where that load is fed by a direct or switched battery connection." wikitext text/x-wiki I/O circuits that are connected to the vehicle battery via switches, relays or resistive/inductive loads, where that load is fed by a direct or switched battery connection. cb173a997261d10323af11b06a5b3a114e50e7e5 0 741 1170 2014-09-11T22:04:32Z Oliver 1 Created page with "Design and Release" wikitext text/x-wiki Design and Release efe80144c1e6ef2dab0534390e70927100f977ec 0 742 1171 2014-09-11T22:04:59Z Oliver 1 Created page with "dBpT = dB picotesla (160 dBpT = 1Gauss )" wikitext text/x-wiki dBpT = dB picotesla (160 dBpT = 1Gauss ) 70db3a829fd1720a6bd173877c0fc0444b17a250 0 743 1172 2014-09-11T22:05:25Z Oliver 1 Created page with "Any electrical transient or electromagnetic phenomenon that may affect the proper operation of an electrical or electronic device (see [[stimulus]])." wikitext text/x-wiki Any electrical transient or electromagnetic phenomenon that may affect the proper operation of an electrical or electronic device (see [[stimulus]]). a4393eda19863a82e3cd1a880d55ad0c663e55b0 0 744 1174 2014-09-11T22:06:45Z Oliver 1 Created page with "Differential Mode Bulk Current Injection." wikitext text/x-wiki Differential Mode Bulk Current Injection. a24b717b98305ff632ef9b7d09e871141d4710f1 0 745 1175 2014-09-11T22:07:04Z Oliver 1 Created page with "Device(s) Under Test. Any electrical or electronic component, module, motor, filter, etc. being tested." wikitext text/x-wiki Device(s) Under Test. Any electrical or electronic component, module, motor, filter, etc. being tested. cfe8eccf833146bdf2212a50d83dc00193f85574 0 746 1176 2014-09-11T22:07:21Z Oliver 1 Created page with "Design Verification (components not constructed from production tooling)." wikitext text/x-wiki Design Verification (components not constructed from production tooling). 2c99fcb9511c031cce34bb7a04558e0eafe9ec38 0 747 1177 2014-09-11T22:07:55Z Oliver 1 Created page with "Electromagnetic Interference" wikitext text/x-wiki Electromagnetic Interference b76738669e0e8a15e3ac2b2723bd2c2491f9987c 0 748 1178 2014-09-11T22:08:19Z Oliver 1 Created page with "Electronic Sub-Assembly" wikitext text/x-wiki Electronic Sub-Assembly 57f66c096899b135a55080643a9580ee0f62f195 0 664 1179 1014 2014-09-11T22:09:04Z Oliver 1 wikitext text/x-wiki *[[Electro Static Disturbance]] *[[Electro Static Discharge]] 80897d07280c31504219c9d9bf9cf885427b1d4e 0 749 1180 2014-09-11T22:09:49Z Oliver 1 Created page with "* ESD - Air Discharge. Test method whereby the electrode of the test generator is brought near the [[DUT]] and discharge is accomplished through an arc to the DUT. * ESD - Con..." wikitext text/x-wiki * ESD - Air Discharge. Test method whereby the electrode of the test generator is brought near the [[DUT]] and discharge is accomplished through an arc to the DUT. * ESD - Contact Discharge. Test method whereby the electrode of the test generator is brought into contact with the DUT and the discharge is triggered by the discharge switch located on the generator. 0f2882080e8a8399da5ea773cb8868a675746f1f 0 750 1181 2014-09-11T22:10:14Z Oliver 1 Created page with "A predictable operating mode intended to minimize adverse effects by restricting or shutting down operation when a significant stimulus has made operation unreliable. Operatio..." wikitext text/x-wiki A predictable operating mode intended to minimize adverse effects by restricting or shutting down operation when a significant stimulus has made operation unreliable. Operation shall recover after the stimulus is removed without permanent loss of function or corruption of stored data or diagnostic information. 49783d047f4fe9b9f91a64a29ffb6ca7acea7dc9 0 751 1182 2014-09-11T22:11:16Z Oliver 1 Created page with "Ford Motor Company including all affiliate brands (like [[Ford]], [[Volvo]], [[Jaguar-Landrover]])." wikitext text/x-wiki Ford Motor Company including all affiliate brands (like [[Ford]], [[Volvo]], [[Jaguar-Landrover]]). 7f78b2fc7cb625273e564a6a16cd8233ef08e5bd 0 752 1183 2014-09-11T22:11:55Z Oliver 1 Created page with "[[Ford]] Product Development System" wikitext text/x-wiki [[Ford]] Product Development System 9ee927dd8a124b4da700f2bc562cab543170265e 0 753 1184 2014-09-11T22:12:52Z Oliver 1 Created page with "Functional Importance Classifications define the importance of [[E/E]] component/subsystem functions with respect to safe vehicle operation. • Class A: Any function that pro..." wikitext text/x-wiki Functional Importance Classifications define the importance of [[E/E]] component/subsystem functions with respect to safe vehicle operation. • Class A: Any function that provides a convenience. • Class B: Any function that enhances, but is not essential to the operation and/or control of the vehicle. • Class C: Any function that controls or affects the essential operation of the vehicle or could confuse the driver or other road users. df3f1ed5c386bd363c3b2835efd3b83ca754b033 1186 1184 2014-09-11T22:14:44Z Oliver 1 wikitext text/x-wiki Functional Importance Classifications define the importance of [[E/E]] component/subsystem functions with respect to safe vehicle operation. *Class A: Any function that provides a convenience. *Class B: Any function that enhances, but is not essential to the operation and/or control of the vehicle. *Class C: Any function that controls or affects the essential operation of the vehicle or could confuse the driver or other road users. abcb6fa12e381bda9f8d1d8dfdc550f47ec1f024 0 754 1185 2014-09-11T22:13:53Z Oliver 1 Created page with "Function Performance Status. The performance of [[DUT]] functions, when subjected to a disturbance, is described by three performance status levels: *Status I: The function sh..." wikitext text/x-wiki Function Performance Status. The performance of [[DUT]] functions, when subjected to a disturbance, is described by three performance status levels: *Status I: The function shall operate as designed (or meet specified limits) during and after exposure to a disturbance. *Status II: The function may deviate from designed performance, to a specified level, during exposure to a disturbance but shall not affect safe operation of the vehicle, safety of its occupants and does not adversely affect customer satisfaction. The function may revert to a fail-safe mode of operation, but shall return to normal operation following removal of the disturbance either automatically or in line with the function's fail-safe recovery strategy. No effect on permanent or temporary memory is allowed. Status II performance, where applicable, is only permissible if the deviation in performance does not affect other related functions requiring Status I performance. *Status III: The function may deviate from designed performance during exposure to a disturbance but shall not affect safe operation of the vehicle or safety of its occupants. Operator action may be required to return the function to normal after the disturbance is removed (e.g. cycle ignition key, replace fuse). No effect on permanent type memory is allowed. Status III performance, where applicable, is only permissible if the deviation in performance does not affect other related functions requiring Status I performance. *Status IV: The device shall not sustain damage, changes in I/O parametric values (resistance, capacitance, leakage current etc.) or a permanent reduction in functionality. 10399a179b3d7806d9fa599c8045409fed1aeaf7 0 755 1187 2014-09-11T22:15:04Z Oliver 1 Created page with "An electromechanical device that stores energy in a magnetic field. Examples include, but not limited to [[solenoid]]s, [[relay]]s, [[buzzer]]s, and electromechanical horns." wikitext text/x-wiki An electromechanical device that stores energy in a magnetic field. Examples include, but not limited to [[solenoid]]s, [[relay]]s, [[buzzer]]s, and electromechanical horns. 1a22f3027755b83bf58cda7dcb8b4e847b3c9c00 0 756 1188 2014-09-11T22:15:42Z Oliver 1 Created page with "Not Applicable" wikitext text/x-wiki Not Applicable 6672b815dc387b62d9d5ec8feba537d77cb2b20e 0 757 1189 2014-09-11T22:16:23Z Oliver 1 Redirected page to [[Printed Circuit Board]] wikitext text/x-wiki #REDIRECT [[Printed Circuit Board]] 13853df1825b701cddc7af9043b365a03f519d97 0 758 1190 2014-09-11T22:17:13Z Oliver 1 Redirected page to [[Pulse Repetition Rate]] wikitext text/x-wiki #REDIRECT [[Pulse Repetition Rate]] cf6b310d39aec353ebd72ef1a5a2f224900d8091 0 759 1191 2014-09-11T22:17:30Z Oliver 1 Created page with "Production Verification (component constructed from production tooling)" wikitext text/x-wiki Production Verification (component constructed from production tooling) 2a9b4405e926002cff329ec6b084da8e5ab03b23 0 760 1192 2014-09-11T22:18:15Z Oliver 1 Redirected page to [[Quasi-Peak Detection]] wikitext text/x-wiki #REDIRECT [[Quasi-Peak Detection]] 09b07fe3f6855566926d5ca08bc1ee1a2d5118f4 0 761 1193 2014-09-11T22:19:05Z Oliver 1 Created page with "Quasi-Peak Detection (QP) is a detection method having specified electrical time constants which, when regularly repeated identical pulses are applied, produces an output volt..." wikitext text/x-wiki Quasi-Peak Detection (QP) is a detection method having specified electrical time constants which, when regularly repeated identical pulses are applied, produces an output voltage which is a fraction of the peak value of the pulses, the fraction increasing towards unity as the pulse repetition rate is increased. b992ea558e4b547f0c3a98432b663d4ab4f6f2a4 0 762 1194 2014-09-11T22:19:37Z Oliver 1 Redirected page to [[Radiated Emission]] wikitext text/x-wiki #REDIRECT [[Radiated Emission]] c1a95a6dfdec7a35d054700a09a02adaf9559b68 0 763 1195 2014-09-11T22:19:58Z Oliver 1 Redirected page to [[Radiated Immunity]] wikitext text/x-wiki #REDIRECT [[Radiated Immunity]] cf07fd1cb3c751945b6399e32f776f8e584cd801 0 764 1196 2014-09-11T22:21:33Z Oliver 1 Redirected page to [[Auto Light Sensor]] wikitext text/x-wiki #REDIRECT [[Auto Light Sensor]] eaded8a64cd51fa77c99038e55c2d8df8c940cf8 0 765 1197 2014-09-11T22:22:20Z Oliver 1 Redirected page to [[Auto High Beam Control]] wikitext text/x-wiki #REDIRECT [[Auto High Beam Control]] a4067852a82b8b9dd8deec7cfd1147cfe2e2a10c 0 766 1198 2014-09-11T22:22:49Z Oliver 1 Redirected page to [[Electronic Control Unit]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit]] 36e857917fdce8ea1b3a7e8262deb830a9919664 0 159 1199 1113 2014-09-11T22:23:49Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ESP || Electronic Stability Program || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 929661e673fc64cb89bb73ef8fe08f283ae09d6b 1214 1199 2014-09-11T22:33:19Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ESP || Electronic Stability Program || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. ee0f68904928653039b68b640804f694d6997bb4 1217 1214 2014-09-11T22:34:44Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ESP || Electronic Stability Program || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |- |LSM || Light Switch Module || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 29e46aaccf8088613606dbefadc7a327ba7a25e3 1221 1217 2014-09-11T22:37:29Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ESP || Electronic Stability Program || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |- |LSM || Light Switch Module || |- |RSM || Rain Sensor Module || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 2686576a21d0e6ac78ad193d3a6714663f00b7a4 1225 1221 2014-09-11T22:40:25Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ESP || Electronic Stability Program || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |- |LSM || Light Switch Module || |- |RSM || Rain Sensor Module || |- |TBM || Trailer Brake Module || |- |TRM || Trailer Module || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. cdaa473a83d8ca2eadc2aa514401e00828edebfb 0 767 1200 2014-09-11T22:24:43Z Oliver 1 Created page with "High Speed Controller Area Network ([[CAN]])" wikitext text/x-wiki High Speed Controller Area Network ([[CAN]]) 3906ba10fc5c1cdc5c1dc19f5aec43efb6c6ca00 0 768 1201 2014-09-11T22:24:51Z Oliver 1 Created page with "Medium Speed Controller Area Network ([[CAN]])" wikitext text/x-wiki Medium Speed Controller Area Network ([[CAN]]) 3b92ec3778a957e27bc92b3ee36051b08da60041 0 769 1202 2014-09-11T22:25:45Z Oliver 1 Redirected page to [[Center High Mounted Stop Lamp]] wikitext text/x-wiki #REDIRECT [[Center High Mounted Stop Lamp]] cf951063b3eac1eaa6b017954104004b3b947a8f 0 770 1203 2014-09-11T22:26:13Z Oliver 1 Redirected page to [[Central Car Configuration]] wikitext text/x-wiki #REDIRECT [[Central Car Configuration]] bbb760135b4a02c6ced683cb967209b76aab4eac 0 771 1204 2014-09-11T22:27:17Z Oliver 1 Redirected page to [[Day Running Lamp]] wikitext text/x-wiki #REDIRECT [[Day Running Lamp]] 45972cabb5a8000c279940a65a4e7287ffbc46d2 0 591 1205 857 2014-09-11T22:27:50Z Oliver 1 Redirected page to [[Diagnostic Trouble Code]] wikitext text/x-wiki #REDIRECT [[Diagnostic Trouble Code]] 24bedd7cfc25c502c26e2ea65f6884b04975277c 0 772 1206 2014-09-11T22:28:00Z Oliver 1 Redirected page to [[Day Running Light]] wikitext text/x-wiki #REDIRECT [[Day Running Light]] ac61cf6f777356c65e9b0791ef77fcf3a8aa1728 0 773 1207 2014-09-11T22:29:26Z Oliver 1 Created page with "Economic Commission of Europe. See [http://www.unece.org/]" wikitext text/x-wiki Economic Commission of Europe. See [http://www.unece.org/] 43da2facbd3d43d7997002e7fedca56f8245bcae 0 774 1208 2014-09-11T22:30:05Z Oliver 1 Created page with "Electrical and Electronic Systems Engineering" wikitext text/x-wiki Electrical and Electronic Systems Engineering e79eb65e500fa6e79f9eacb6bbac7c74c8ac5322 0 775 1209 2014-09-11T22:30:33Z Oliver 1 Redirected page to [[Global Central Configuration]] wikitext text/x-wiki #REDIRECT [[Global Central Configuration]] 225cfbab6bf87a5dcc32df9c37343ed3488506c7 0 776 1210 2014-09-11T22:31:14Z Oliver 1 Created page with "Halogen bulb with dual filament (55W/15W)" wikitext text/x-wiki Halogen bulb with dual filament (55W/15W) 883efbb69d01ca9162926647f0ab926998cf18fa 0 777 1211 2014-09-11T22:31:28Z Oliver 1 Created page with "Halogen bulb with single filament (55W, 1500lm)." wikitext text/x-wiki Halogen bulb with single filament (55W, 1500lm). bce44b6e632404ae4b40d1172d8dd618f25de005 0 778 1212 2014-09-11T22:31:58Z Oliver 1 Redirected page to [[Home Safe Lighting]] wikitext text/x-wiki #REDIRECT [[Home Safe Lighting]] cd61bb2026e6ad53ffb52c2b7769d3ab446bb657 0 779 1213 2014-09-11T22:32:39Z Oliver 1 Redirected page to [[Electronic Control Unit]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit]] 36e857917fdce8ea1b3a7e8262deb830a9919664 0 780 1215 2014-09-11T22:33:51Z Oliver 1 Created page with "Kilometers per hour (kph = km/h)" wikitext text/x-wiki Kilometers per hour (kph = km/h) 6e1589514a501fe51007564d8d7b673fad03b0d2 0 781 1216 2014-09-11T22:34:41Z Oliver 1 Redirected page to [[Electronic Control Unit]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit]] 36e857917fdce8ea1b3a7e8262deb830a9919664 0 782 1218 2014-09-11T22:35:13Z Oliver 1 Redirected page to [[Multi Function Display]] wikitext text/x-wiki #REDIRECT [[Multi Function Display]] cf5b32cd46e3e161dc4eac9bb3f777842fd8f3fd 0 783 1219 2014-09-11T22:35:42Z Oliver 1 Redirected page to [[Multi Function Switch]] wikitext text/x-wiki #REDIRECT [[Multi Function Switch]] e31494affe08aace706e7713d9afff7ff58d4caa 0 784 1220 2014-09-11T22:36:14Z Oliver 1 Redirected page to [[Master Light Switch]] wikitext text/x-wiki #REDIRECT [[Master Light Switch]] a2ea6139c91662bf05f8812452ee50f2503f60eb 0 785 1222 2014-09-11T22:38:11Z Oliver 1 Redirected page to [[Electronic Control Unit#RSM]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#RSM]] c36744a8fabf4547b10294e597985d003a1d7093 0 786 1223 2014-09-11T22:38:54Z Oliver 1 Redirected page to [[System Design Specification]] wikitext text/x-wiki #REDIRECT [[System Design Specification]] 18a7e2f96149b073a9a50f55c9c2347fe084bd55 0 787 1224 2014-09-11T22:39:34Z Oliver 1 Created page with "(Sub-)system Requirement Document." wikitext text/x-wiki (Sub-)system Requirement Document. 69795457d088b91ddd88dc2c6fd18d88a264a1a9 0 788 1226 2014-09-11T22:40:57Z Oliver 1 Redirected page to [[Electronic Control Unit#TRM]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#TRM]] fb120c5940794990fbfff000718233707d3ebfd5 0 789 1227 2014-09-11T22:41:04Z Oliver 1 Redirected page to [[Electronic Control Unit#TBM]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#TBM]] 944b80fdbf750897714ce88f37b9abfefedf78a7 0 790 1228 2014-09-11T22:42:28Z Oliver 1 Redirected page to [[Configuration Management]] wikitext text/x-wiki #REDIRECT [[Configuration Management]] 2f0103c446c04bd7d3c141ac0778879f52583e99 0 791 1229 2014-09-11T22:43:50Z Oliver 1 Created page with "[[Category:hardware]] *A-sample *B-sample *C-sample *D-sample" wikitext text/x-wiki [[Category:hardware]] *A-sample *B-sample *C-sample *D-sample 99f351b4167dcdb80784830a1e1286af6ad3cd1f 1245 1229 2014-09-12T06:39:48Z Oliver 1 wikitext text/x-wiki [[Category:hardware]] *A-sample *B-sample *C-sample *D-sample: Hardware sample intended for series production 16c5b50614381d79c0d18fedf7816be243e3397c 0 705 1230 1120 2014-09-11T22:46:57Z Oliver 1 Redirected page to [[Electronic Control Unit#AFS]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#AFS]] 46f5d73b8be0a81cfbaf757266dd1dd07adde254 0 792 1231 2014-09-11T22:49:06Z Oliver 1 Created page with "Änderungs-Anregungs-Schein = Change Request document" wikitext text/x-wiki Änderungs-Anregungs-Schein = Change Request document 76b7793cd7747ad1bcbb434b6fb51a32761d00cd 1263 1231 2014-09-12T06:54:24Z Oliver 1 wikitext text/x-wiki Änderungs-Anregungs-Schein = [[Change Request]] document f14f5d3cebf35b2fb5f926191d28b0cf9384fe0b 0 159 1232 1225 2014-09-11T23:08:34Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ESP || Electronic Stability Program || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |- |LSM || Light Switch Module || |- |RSM || Rain Sensor Module || |- |TBM || Trailer Brake Module || |- |TRM || Trailer Module || |- |AFS || Active Front Steering<br>Advanced Frontlighting System || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 5dcf496f4107f9effa5b126c01e517560e45bd0e 0 793 1233 2014-09-12T06:26:22Z Oliver 1 Created page with "Automatische Leuchtweitenregulierung ([[Automatic Vertical Aim Control]])" wikitext text/x-wiki Automatische Leuchtweitenregulierung ([[Automatic Vertical Aim Control]]) cf2c52f8c5991b2b84a6b53bc9c4b1d7da42d37e 0 794 1234 2014-09-12T06:27:14Z Oliver 1 Redirected page to [[Automatic Vertical Aim Control]] wikitext text/x-wiki #REDIRECT [[Automatic Vertical Aim Control]] 44b2bf969bd86298dfcd40487bf7f783f5ba67c8 0 795 1235 2014-09-12T06:28:02Z Oliver 1 Created page with "Bestellanforderung => purchase requisition" wikitext text/x-wiki Bestellanforderung => purchase requisition c43af56f3391dcd557cefc328a83af6cbe935fbe 0 796 1236 2014-09-12T06:30:27Z Oliver 1 Created page with "[[Category:hardware]] The Bill of Material (BOM) lists all used components of a system or another component." wikitext text/x-wiki [[Category:hardware]] The Bill of Material (BOM) lists all used components of a system or another component. 1a72f5ef50ef0f2ce7a213d7e1989ff95e407448 0 797 1237 2014-09-12T06:31:55Z Oliver 1 Created page with "[[Category:hardware]] Bestellvorschrift => [[Order Specification]]" wikitext text/x-wiki [[Category:hardware]] Bestellvorschrift => [[Order Specification]] 602d6f817decfcdb54851a1215f57accbe1e1733 0 798 1238 2014-09-12T06:32:33Z Oliver 1 Redirected page to [[Change Control Board]] wikitext text/x-wiki #REDIRECT [[Change Control Board]] 15ab4727050d136852407c834ed1369d82b41dfb 0 799 1239 2014-09-12T06:33:49Z Oliver 1 Redirected page to [[Dynamic Bending Light]] wikitext text/x-wiki #REDIRECT [[Dynamic Bending Light]] 09ed3af7cb35e8bc6a0126d62700f83ca68ba796 0 772 1240 1206 2014-09-12T06:35:27Z Oliver 1 Redirected page to [[Daytime Running Light]] wikitext text/x-wiki #REDIRECT [[Daytime Running Light]] decb03bebc650ee68d76ca0a32450dc56dc7acec 0 771 1241 1204 2014-09-12T06:35:38Z Oliver 1 Redirected page to [[Daytime Running Light]] wikitext text/x-wiki #REDIRECT [[Daytime Running Light]] decb03bebc650ee68d76ca0a32450dc56dc7acec 0 800 1242 2014-09-12T06:36:26Z Oliver 1 Created page with "Extended [[Fog Light]]" wikitext text/x-wiki Extended [[Fog Light]] 01b17d6b0058fdd4b7757d3c52ff39f18ed22d98 1243 1242 2014-09-12T06:37:01Z Oliver 1 Redirected page to [[Extended Fog Light]] wikitext text/x-wiki #REDIRECT [[Extended Fog Light]] d07ebda922004fcd3076b0845b9e90d66342a9f6 0 801 1244 2014-09-12T06:37:09Z Oliver 1 Redirected page to [[Fog Light]] wikitext text/x-wiki #REDIRECT [[Fog Light]] 8c81b082d66ff36628780bd02625ed6b06ae1c19 0 802 1246 2014-09-12T06:39:57Z Oliver 1 Created page with "[[Category:hardware]] Erstmuster-Prüfbericht => Test report of hardware [[Hardware sample|D-Sample]]." wikitext text/x-wiki [[Category:hardware]] Erstmuster-Prüfbericht => Test report of hardware [[Hardware sample|D-Sample]]. 9f9a1bd69940152157219346dc30fea8a373cb75 0 803 1247 2014-09-12T06:40:49Z Oliver 1 Redirected page to [[Failure Mode Effect Analysis]] wikitext text/x-wiki #REDIRECT [[Failure Mode Effect Analysis]] 7cb19ef56f1c6089bea58cca035d88ea66b83d0c 0 804 1248 2014-09-12T06:41:12Z Oliver 1 Created page with "Fertigungsvorschrift => [[Production specification]]" wikitext text/x-wiki Fertigungsvorschrift => [[Production specification]] d5ee7932a66cc65ed322ba6658e9f2b989fb0eef 0 805 1249 2014-09-12T06:42:23Z Oliver 1 Redirected page to [[High Beam]] wikitext text/x-wiki #REDIRECT [[High Beam]] 8ca7e6021629d2306101329157d571c84e013a1c 0 806 1250 2014-09-12T06:43:06Z Oliver 1 Created page with "High beam (HB) (lamp). High Beam Automatic (HBA)." wikitext text/x-wiki High beam (HB) (lamp). High Beam Automatic (HBA). 0d04de37cadd18115fce0d160e0b30df08278daf 0 807 1251 2014-09-12T06:43:15Z Oliver 1 Redirected page to [[High Beam]] wikitext text/x-wiki #REDIRECT [[High Beam]] 8ca7e6021629d2306101329157d571c84e013a1c 0 808 1252 2014-09-12T06:43:41Z Oliver 1 Created page with "#REDIRECT [Hardware In the Loop]]" wikitext text/x-wiki #REDIRECT [Hardware In the Loop]] 7dfb0266a79912d7f5e4c1ef185de7741c52fce6 0 809 1253 2014-09-12T06:44:22Z Oliver 1 Redirected page to [[Low Beam]] wikitext text/x-wiki #REDIRECT [[Low Beam]] 56075f4f667aef72f04a8ec0ef7fea39fda2ea00 0 810 1254 2014-09-12T06:45:07Z Oliver 1 Created page with "Lastenheft => Customer Requirement Specification" wikitext text/x-wiki Lastenheft => Customer Requirement Specification 002b0fe9e8f772b3229b626cd7e8a40167c1e827 0 811 1255 2014-09-12T06:46:29Z Oliver 1 Created page with "Leuchtweitenregulierung => [[Vertical Aim Control]]" wikitext text/x-wiki Leuchtweitenregulierung => [[Vertical Aim Control]] a9af6da905c7679b935eddbc81b2fc2b043234ba 0 812 1256 2014-09-12T06:47:26Z Oliver 1 Created page with "Module requirements specification" wikitext text/x-wiki Module requirements specification 5a5937a9c4d398ff26fb123d0503ac69d956dc1f 0 813 1257 2014-09-12T06:48:49Z Oliver 1 Created page with "Motor Industry Software Reliability Association is a standard of automotive industry for SW programming. See [http://www.misra.org.uk/]" wikitext text/x-wiki Motor Industry Software Reliability Association is a standard of automotive industry for SW programming. See [http://www.misra.org.uk/] ed202871ef0ba059682f482ccdfa09466071ab7e 0 814 1258 2014-09-12T06:49:41Z Oliver 1 Redirected page to [[Motorway Light]] wikitext text/x-wiki #REDIRECT [[Motorway Light]] 1b97f7c9a808acce6a7a16ac0bc0308664b015f4 0 815 1259 2014-09-12T06:50:19Z Oliver 1 Redirected page to [[Milestone Trend Analysis]] wikitext text/x-wiki #REDIRECT [[Milestone Trend Analysis]] 2fa2e4649a713339e30d46851363e5d4612f7647 0 816 1260 2014-09-12T06:50:56Z Oliver 1 Redirected page to [[Optical Vertical Aim Control]] wikitext text/x-wiki #REDIRECT [[Optical Vertical Aim Control]] d9bbe6ef1309d0b4ee22d4fe386a8267a7ebb0da 0 817 1261 2014-09-12T06:52:05Z Oliver 1 Redirected page to [[Product Change Notification]] wikitext text/x-wiki #REDIRECT [[Product Change Notification]] aec57e4f22d28b9a7b08a580086d132782f3b12d 0 818 1262 2014-09-12T06:53:02Z Oliver 1 Redirected page to [[Project Management]] wikitext text/x-wiki #REDIRECT [[Project Management]] 7f115c5b0258f18a6b43e3c621731dedec8e15f1 0 80 1264 83 2014-09-12T06:54:32Z Oliver 1 wikitext text/x-wiki Request for Change. See [[Change Request]] 6c363f13283c48408a9cddf8419d66a715555105 0 819 1265 2014-09-12T07:05:37Z Oliver 1 Redirected page to [[Static Bending Light]] wikitext text/x-wiki #REDIRECT [[Static Bending Light]] 9ba63526a7ca52f8577fe452b03607740f171b6a 0 820 1266 2014-09-12T07:05:55Z Oliver 1 Created page with "Signal-Extended [[Fog Light]]" wikitext text/x-wiki Signal-Extended [[Fog Light]] 5fc471194f3872154209706c11c435a0b8a31630 0 821 1267 2014-09-12T07:06:33Z Oliver 1 Redirected page to [[ECU]] wikitext text/x-wiki #REDIRECT [[ECU]] e2243fc6c282983b7b78cb8ea8db08f5e2aeac1c 1268 1267 2014-09-12T07:07:26Z Oliver 1 Redirected page to [[Electronic Control Unit]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit]] 36e857917fdce8ea1b3a7e8262deb830a9919664 0 822 1269 2014-09-12T07:08:11Z Oliver 1 Created page with "* [[Side Marker]] * [[Stepper Motor]]" wikitext text/x-wiki * [[Side Marker]] * [[Stepper Motor]] ffe7b36aa19b20db70ba1a84b29c3729e0505c6b 0 823 1270 2014-09-12T07:09:15Z Oliver 1 Redirected page to [[Worst Case Circuit Analysis]] wikitext text/x-wiki #REDIRECT [[Worst Case Circuit Analysis]] 1c4e621bbde0635737ce7fd9acbef99aedfc7c3d 0 824 1271 2014-09-12T07:11:17Z Oliver 1 Redirected page to [[Software Requirements Specification]] wikitext text/x-wiki #REDIRECT [[Software Requirements Specification]] 3af3b90bc1c1f53a41d0a2238f51b3643025ae29 0 825 1272 2014-09-12T07:13:44Z Oliver 1 Redirected page to [[Tourist Function]] wikitext text/x-wiki #REDIRECT [[Tourist Function]] 7fe030ff654ba4b05ddd03b14ee1c743f5167ac8 0 826 1273 2014-09-12T07:13:55Z Oliver 1 Redirected page to [[Turn Indicator]] wikitext text/x-wiki #REDIRECT [[Turn Indicator]] 12d84eb3563a8d948cfc180149a6d59cd8baed15 0 827 1274 2014-09-12T07:14:11Z Oliver 1 Redirected page to [[Vertical Aim Control]] wikitext text/x-wiki #REDIRECT [[Vertical Aim Control]] c117604f234148c260f090ac064e9a4a4d900cb7 0 828 1275 2014-09-12T07:14:47Z Oliver 1 Created page with "Zentrale Verfahrensanweisung" wikitext text/x-wiki Zentrale Verfahrensanweisung 3e8b9ff493ca33d56d5a1927acb40b29366d02e1 0 829 1276 2014-09-12T08:13:39Z Oliver 1 Redirected page to [[Ultrasonic Park Assist]] wikitext text/x-wiki #REDIRECT [[Ultrasonic Park Assist]] 10c5a4d4972dd5ac1edbd474c6fe7baa2ce0cb05 0 830 1277 2014-09-12T08:14:48Z Oliver 1 Redirected page to [[Park Distance Control]] wikitext text/x-wiki #REDIRECT [[Park Distance Control]] 0f3db7a519afd91c5db2c82e7cba152ad918017a 0 831 1278 2014-09-18T12:52:20Z Oliver 1 Redirected page to [[Supervised Entity]] wikitext text/x-wiki #REDIRECT [[Supervised Entity]] f4fb9e788263390687848c88393b7c030205ee7e 0 832 1279 2014-09-18T12:57:52Z Oliver 1 Redirected page to [[Supervision Cycle]] wikitext text/x-wiki #REDIRECT [[Supervision Cycle]] 3b889868ad5db15d0fd156fd407db527d68344a6 0 564 1280 823 2014-09-18T13:02:23Z Oliver 1 wikitext text/x-wiki The Watchdog [[Manager]] (WdgM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === = Terms = * Alive Counter: An independent data resource in the Watchdog Manager in context of a Checkpoint to track and handle its amount of Alive Indications. * Alive Indication: An indication provided by a Checkpoint of a Supervised Entity to signal its aliveness to the Watchdog Manager. * Alive Supervision: Kind of supervision that checks if a Supervised Entity executed sufficiently often and not too often (including tolerances). * Checkpoint: A point in the control flow of a Supervised Entity where the activity is reported to the Watchdog Manager. * Deadline Supervision: Kind of supervision that checks if the execution time between two Checkpoints are lower then a given upper execution time limit. * Deadline Start Checkpoint: A Checkpoint for which Deadline Supervision is configured and which is a starting point for a particular Deadline Supervision. * Deadline End Checkpoint: A Checkpoint for which Deadline Supervision is configured and which is a ending point for a particular Deadline Supervision. It is possible that a Checkpoint is both a Deadline Start Checkpoint and Deadline End Checkpoint – if Deadline Supervision is chained. * Expired Supervision Cycle: A Supervision Cycle where the alive-supervision has failed its two escalation steps (Alive Counter fails the expected amount of Alive Indications (including tolerances) more often than the allowed amount of failed reference cycles). * Failed Supervision Reference Cycle: A Supervision Reference Cycle that ends with a detected deviation (including tolerances) between the Alive Counter and the expected amount of Alive Indications. * Global Supervision Status: Status that summarizes the Local Supervision Status of all Supervised Entities. * Graph: A set of Checkpoints connected through Transitions, where at least one of Checkpoints is an Initial Checkpoint. There is a path (through Transitions) between any two Checkpoints of the Graph * External Graph: Graph that may involve more than one Supervised Entity. Its configuration is mode-dependent. * External Transition: An External Transition is a transition between two Checkpoints, where the Checkpoints belong to different Supervised Entities. * Local Supervision Status: Status that represents the current result of alive-supervision of a single Supervised Entity. * Logical Supervision: Kind of online supervision of software that checks if the software (Supervised Entity or set of Supervised Entities) is executed in the sequence defined by the programmer (by the developed code). * Internal Graph: Graph that may not span over several Supervised Entity. Its configuration is mode-independent and can be disabled by disabling the corresponding Supervised Entity. * Internal Transition: An I nternal Transition is a transition between two Checkpoints of a Supervised Entity. * Mode: A mode is a certain set of states of the various state machines that are running in the vehicle that are relevant to a particular entity, e.g. a SW-C, a BSW module, an application, a whole vehicle In its lifetime, an entity changes between a set of mutually exclusive modes. These changes are triggered by environmental data, e.g. signal reception, operation invocation. In the context of the Watchdog Manager a mode is defined by a set of configuration options. The set of Supervised Entities to be supervised may vary from mode to mode. * Supervised Entity: A software entity which is included in the supervision of the Watchdog Manager. Each Supervised Entity has exactly one identifier. A Supervised Entity denotes a collection of Checkpoints within a Software Component or Basic Software Module. There may be zero, one or more Supervised Entities in a Software Component or Basic Software Module. * Supervised Entity Identifier: An Identifier that identifies uniquely a Supervised Entity within an Application. * Supervision Counter: An independent data resource in context of a Supervised Entity which is updated by the Watchdog Manager during each supervision cycle and which is used by the alive-supervision algorithm to perform the check against counted Alive Indications. * Supervision Cycle: The time period of Watchdog Manager, where the cyclic Alive Supervision is performed. This is done by the main function of Watchdog Manager. * Supervision Reference Cycle: The amount of Supervision Cycles to be used as reference by the Alive Supervision to perform the check of counted Alive Indications (individually for each Supervised Entity). d3db2cba95379929cc5c232eb8dd9b068b4bc2bc 0 833 1281 2014-09-23T08:28:06Z Oliver 1 Redirected page to [[SAE J1939]] wikitext text/x-wiki #REDIRECT [[SAE J1939]] 1e8bc54cf9f3f909257a0acc99e0fef112af2eeb 0 808 1282 1252 2014-09-24T07:23:59Z Oliver 1 Redirected page to [[Hardware In the Loop]] wikitext text/x-wiki #REDIRECT [[Hardware In the Loop]] b0347d26a98ac289fdfa11f31c8da015e273443e 0 84 1283 356 2014-09-24T07:24:45Z Oliver 1 wikitext text/x-wiki *[[Safety Integrity Level]] *[[Software in the Loop]] 55647bd0f3077292cff4289834b1fc394eaec7d2 0 834 1284 2014-09-24T07:25:23Z Oliver 1 Created page with "TODO" wikitext text/x-wiki TODO b698c11e84460ed5999bfeb5cbf25b865c238f3c 0 835 1285 2014-09-24T07:25:57Z Oliver 1 Redirected page to [[Restbus Simulation]] wikitext text/x-wiki #REDIRECT [[Restbus Simulation]] 88c873d625cb887e7c55503f489b64fdae27f279 0 836 1286 2014-09-24T07:26:13Z Oliver 1 Redirected page to [[Restbus Simulation]] wikitext text/x-wiki #REDIRECT [[Restbus Simulation]] 88c873d625cb887e7c55503f489b64fdae27f279 0 837 1287 2014-09-24T21:00:43Z Oliver 1 Redirected page to [[ISO 14229 Negative response codes]] wikitext text/x-wiki #REDIRECT [[ISO 14229 Negative response codes]] 9411e2123d4ac05783a207a0993a76efff82296b 0 838 1288 2014-09-24T21:01:05Z Oliver 1 Redirected page to [[ISO 14229 Negative response codes]] wikitext text/x-wiki #REDIRECT [[ISO 14229 Negative response codes]] 9411e2123d4ac05783a207a0993a76efff82296b 0 839 1289 2014-09-24T21:12:23Z Oliver 1 Redirected page to [[ISO 14229 Negative response codes]] wikitext text/x-wiki #REDIRECT [[ISO 14229 Negative response codes]] 9411e2123d4ac05783a207a0993a76efff82296b 0 840 1290 2014-09-24T21:34:22Z Oliver 1 Created page with "The negative response codes (NRC) are divided into 3 ranges: * 0x00: positiveResponse parameter value for server internal implementation, * 0x01 – 0x7F: communication relate..." wikitext text/x-wiki The negative response codes (NRC) are divided into 3 ranges: * 0x00: positiveResponse parameter value for server internal implementation, * 0x01 – 0x7F: communication related negative response codes, * 0x80 – 0xFF: negative response codes for specific conditions that are not correct at the point in time the request is received by the server. These response codes may be utilized whenever response code 0x22 (conditionsNotCorrect) is listed as valid in order to report more specifically why the requested action can not be taken. {| !value !responseCode !Description |- | 0x00 || positiveResponse | This response code shall not be used in a negative response message. This positiveResponse parameter value is reserved for server internal implementation. |- | 0x01 - 0x0F || ISOSAEReserved | This range of values is reserved by this document for future definition. |- | 0x10 || generalReject | This response code indicates that the requested action has been rejected by the server. The generalReject response code shall only be implemented in the server if none of the negative response codes defined in this document meet the needs of the implementation. At no means shall this response code be a general replacement for other response codes defined. |- | 0x11 || serviceNotSupported | This response code indicates that the requested action will not be taken because the server does not support the requested service. The server shall send this response code in case the client has sent a request message with a service identifier, which is either unknown or not supported by the server. Therefore this negative response code is not shown in the list of negative response codes to be supported for a diagnostic service, because this negative response code is not applicable for supported services. |- | 0x12 || subFunctionNotSupported | This response code indicates that the requested action will not be taken because the server does not support the service specific parameters of the request message. The server shall send this response code in case the client has sent a request message with a known and supported service identifier but with "sub function“ which is either unknown or not supported. |- | 0x13 || incorrectMessageLengthOrInvalidFormat | This response code indicates that the requested action will not be taken because the length of the received request message does not match the prescribed length for the specified service or the format of the parameters do not match the prescribed format for the specified service. |- | 0x14 || responseTooLong | This response code shall be reported by the server if the response to be generated exceeds the maximum number of bytes available by the underlying network layer. |- | 0x15 - 0x20 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x21 || busyRepeatReques | This response code indicates that the server is temporarily too busy to perform the requested operation. In this circumstance the client shall perform repetition of the "identical request message" or "another request message". The repetition of the request shall be delayed by a time specified in the respective implementation documents. Example: In a multi-client environment the diagnostic request of one client might be blocked temporarily by a NRC $21 while a different client finishes a diagnostic task. NOTE If the server is able to perform the diagnostic task but needs additional time to finish the task and prepare the response, the NRC 0x78 shall be used instead of NRC 0x21. This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- | 0x22 || conditionsNotCorrect | This response code indicates that the requested action will not be taken because the server prerequisite conditions are not met. |- | 0x23 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x24 || requestSequenceError | This response code indicates that the requested action will not be taken because the server expects a different sequence of request messages or message as sent by the client. This may occur when sequence sensitive requests are issued in the wrong order. EXAMPLE A successful SecurityAccess service specifies a sequence of requestSeed and sendKey as sub-functions in the request messages. If the sequence is sent different by the client the server shall send a negative response message with the negative response code 0x24 (requestSequenceError). |- | 0x25 - 0x30 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x31 || requestOutOfRange | This response code indicates that the requested action will not be taken because the server has detected that the request message contains a parameter which attempts to substitute a value beyond its range of authority (e.g. attempting to substitute a data byte of 111 when the data is only defined to 100), or which attempts to access a dataIdentifier/routineIdentifer that is not supported or not supported in active session. This response code shall be implemented for all services, which allow the client to read data, write data or adjust functions by data in the server. |- | 0x32 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x33 || securityAccessDenied | This response code indicates that the requested action will not be taken because the server's security strategy has not been satisfied by the client. The server shall send this response code if one of the following cases occur: * the test conditions of the server are not met, * the required message sequence e.g. DiagnosticSessionControl, securityAccess is not met, * the client has sent a request message which requires an unlocked server. <br>Beside the mandatory use of this negative response code as specified in the applicable services within this standard, this negative response code can also be used for any case where security is required and is not yet granted to perform the required service. |- | 0x34 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x35 || invalidKey | This response code indicates that the server has not given security access because the key sent by the client did not match with the key in the server's memory. This counts as an attempt to gain security. The server shall remain locked and increment its internal securityAccessFailed counter. |- | 0x36 || exceedNumberOfAttempts | This response code indicates that the requested action will not be taken because the client has unsuccessfully attempted to gain security access more times than the server's security strategy will allow. |- | 0x37 || requiredTimeDelayNotExpired | This response code indicates that the requested action will not be taken because the client's latest attempt to gain security access was initiated before the server's required timeout period had elapsed. |- | 0x38 - 0x4F || reservedByExtendedDataLinkSecurityDocument | This range of values is reserved by ISO 15764 Extended data link security. |- | 0x50 - 0x6F || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x70 || uploadDownloadNotAccepted | This response code indicates that an attempt to upload/download to a server's memory cannot be accomplished due to some fault conditions. |- | 0x71 || transferDataSuspended | This response code indicates that a data transfer operation was halted due to some fault. The active transferData sequence shall be aborted. |- | 0x72 || generalProgrammingFailure | This response code indicates that the server detected an error when erasing or programming a memory location in the permanent memory device (e.g. Flash Memory). |- | 0x73 || wrongBlockSequenceCounter | This response code indicates that the server detected an error in the sequence of blockSequenceCounter values. Note that the repetition of a TransferData request message with a blockSequenceCounter equal to the one included in the previous TransferData request message shall be accepted by the server. |- | 0x74 - 0x77 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x78 || requestCorrectlyReceived-ResponsePending | This response code indicates that the request message was received correctly, and that all parameters in the request message were valid, but the action to be performed is not yet completed and the server is not yet ready to receive another request. As soon as the requested service has been completed, the server shall send a positive response message or negative response message with a response code different from this. The negative response message with this response code may be repeated by the server until the requested service is completed and the final response message is sent. This response code might impact the application layer timing parameter values. The detailed specification shall be included in the data link specific implementation document. This response code shall only be used in a negative response message if the server will not be able to receive further request messages from the client while completing the requested diagnostic service. When this response code is used, the server shall always send a final response (positive or negative) independent of the suppressPosRspMsgIndicationBit value. A typical example where this response code may be used is when the client has sent a request message, which includes data to be programmed or erased in flash memory of the server. If the programming/erasing routine (usually executed out of RAM) is not able to support serial communication while writing to the flash memory the server shall send a negative response message with this response code. This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- | 0x79 - 0x7D || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x7E || subFunctionNotSupportedInActiveSession | This response code indicates that the requested action will not be taken because the server does not support the requested sub-function in the session currently active. Within the programmingSession negative response code 0x12 (subFunctionNotSupported) may optionally be reported instead of negative response code 0x7F (subFunctionNotSupportedInActiveSession). This response code shall only be used when the requested sub-function is known to be supported in another session, otherwise response code 0x12 (subFunctionNotSupported) shall be used. This response code shall be supported by each diagnostic service with a sub-function parameter, if not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- | 0x7F || serviceNotSupportedInActiveSession | This response code indicates that the requested action will not be taken because the server does not support the requested service in the session currently active. This response code shall only be used when the requested service is known to be supported in another session, otherwise response code 0x11 (serviceNotSupported) shall be used. This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- | 0x80 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x81 || rpmTooHigh | This response code indicates that the requested action will not be taken because the server prerequisite condition for RPM is not met (current RPM is above a pre-programmed maximum threshold). |- | 0x82 || rpmTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for RPM is not met (current RPM is below a pre-programmed minimum threshold). |- | 0x83 || engineIsRunning | This is required for those actuator tests which cannot be actuated while the Engine is running. This is different from RPM too high negative response and needs to be allowed. |- | 0x84 || engineIsNotRunning | This is required for those actuator tests which cannot be actuated unless the Engine is running. This is different from RPM too low negative response, and needs to be allowed. |- | 0x85 || engineRunTimeTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for engine run time is not met (current engine run time is below a preprogrammed limit). |- | 0x86 || temperatureTooHigh | This response code indicates that the requested action will not be taken because the server prerequisite condition for temperature is not met (current temperature is above a preprogrammed maximum threshold). |- | 0x87 || temperatureTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for temperature is not met (current temperature is below a preprogrammed minimum threshold). |- | 0x88 || vehicleSpeedTooHigh | This response code indicates that the requested action will not be taken because the server prerequisite condition for vehicle speed is not met (current VS is above a pre-programmed maximum threshold). |- | 0x89 || vehicleSpeedTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for vehicle speed is not met (current VS is below a pre-programmed minimum threshold). |- | 0x8A || throttle/PedalTooHigh | This response code indicates that the requested action will not be taken because the server prerequisite condition for throttle/pedal position is not met (current TP/APP is above a preprogrammed maximum threshold). |- | 0x8B || throttle/PedalTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for throttle/pedal position is not met (current TP/APP is below a preprogrammed minimum threshold). |- | 0x8C || transmissionRangeNotInNeutral | This response code indicates that the requested action will not be taken because the server prerequisite condition for being in neutral is not met (current transmission range is not in neutral). |- | 0x8D || transmissionRangeNotInGear | This response code indicates that the requested action will not be taken because the server prerequisite condition for being in gear is not met (current transmission range is not in gear). |- | 0x8E || ISOSAEReserved | This range of values is reserved by this document for future definition. |- | 0x8F || brakeSwitch(es)NotClosed (Brake Pedal not pressed or not applied) | For safety reasons, this is required for certain tests before it begins, and must be maintained for the entire duration of the test. |- | 0x90 || shifterLeverNotInPark | For safety reasons, this is required for certain tests before it begins, and must be maintained for the entire duration of the test. |- | 0x91 || torqueConverterClutchLocked | This response code indicates that the requested action will not be taken because the server prerequisite condition for torque converter clutch is not met (current TCC status above a preprogrammed limit or locked). |- | 0x92 || voltageTooHigh | This response code indicates that the requested action will not be taken because the server prerequisite condition for voltage at the primary pin of the server (ECU) is not met (current voltage is above a pre-programmed maximum threshold). |- | 0x93 || voltageTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for voltage at the primary pin of the server (ECU) is not met (current voltage is below a pre-programmed maximum threshold). |- | 0x94 - 0xFE || reservedForSpecificConditionsNotCorrect | This range of values is reserved for future definition. |- | 0xFF || ISOSAEReserved | This range of values is reserved for future definition. |} cd6d9a8d003382db4749c89bf059bbd829d01b56 1291 1290 2014-09-24T21:35:00Z Oliver 1 wikitext text/x-wiki The negative response codes (NRC) are divided into 3 ranges: * 0x00: positiveResponse parameter value for server internal implementation, * 0x01 – 0x7F: communication related negative response codes, * 0x80 – 0xFF: negative response codes for specific conditions that are not correct at the point in time the request is received by the server. These response codes may be utilized whenever response code 0x22 (conditionsNotCorrect) is listed as valid in order to report more specifically why the requested action can not be taken. {| class="wikitable" !value !responseCode !Description |- | 0x00 || positiveResponse | This response code shall not be used in a negative response message. This positiveResponse parameter value is reserved for server internal implementation. |- | 0x01 - 0x0F || ISOSAEReserved | This range of values is reserved by this document for future definition. |- | 0x10 || generalReject | This response code indicates that the requested action has been rejected by the server. The generalReject response code shall only be implemented in the server if none of the negative response codes defined in this document meet the needs of the implementation. At no means shall this response code be a general replacement for other response codes defined. |- | 0x11 || serviceNotSupported | This response code indicates that the requested action will not be taken because the server does not support the requested service. The server shall send this response code in case the client has sent a request message with a service identifier, which is either unknown or not supported by the server. Therefore this negative response code is not shown in the list of negative response codes to be supported for a diagnostic service, because this negative response code is not applicable for supported services. |- | 0x12 || subFunctionNotSupported | This response code indicates that the requested action will not be taken because the server does not support the service specific parameters of the request message. The server shall send this response code in case the client has sent a request message with a known and supported service identifier but with "sub function“ which is either unknown or not supported. |- | 0x13 || incorrectMessageLengthOrInvalidFormat | This response code indicates that the requested action will not be taken because the length of the received request message does not match the prescribed length for the specified service or the format of the parameters do not match the prescribed format for the specified service. |- | 0x14 || responseTooLong | This response code shall be reported by the server if the response to be generated exceeds the maximum number of bytes available by the underlying network layer. |- | 0x15 - 0x20 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x21 || busyRepeatReques | This response code indicates that the server is temporarily too busy to perform the requested operation. In this circumstance the client shall perform repetition of the "identical request message" or "another request message". The repetition of the request shall be delayed by a time specified in the respective implementation documents. Example: In a multi-client environment the diagnostic request of one client might be blocked temporarily by a NRC $21 while a different client finishes a diagnostic task. NOTE If the server is able to perform the diagnostic task but needs additional time to finish the task and prepare the response, the NRC 0x78 shall be used instead of NRC 0x21. This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- | 0x22 || conditionsNotCorrect | This response code indicates that the requested action will not be taken because the server prerequisite conditions are not met. |- | 0x23 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x24 || requestSequenceError | This response code indicates that the requested action will not be taken because the server expects a different sequence of request messages or message as sent by the client. This may occur when sequence sensitive requests are issued in the wrong order. EXAMPLE A successful SecurityAccess service specifies a sequence of requestSeed and sendKey as sub-functions in the request messages. If the sequence is sent different by the client the server shall send a negative response message with the negative response code 0x24 (requestSequenceError). |- | 0x25 - 0x30 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x31 || requestOutOfRange | This response code indicates that the requested action will not be taken because the server has detected that the request message contains a parameter which attempts to substitute a value beyond its range of authority (e.g. attempting to substitute a data byte of 111 when the data is only defined to 100), or which attempts to access a dataIdentifier/routineIdentifer that is not supported or not supported in active session. This response code shall be implemented for all services, which allow the client to read data, write data or adjust functions by data in the server. |- | 0x32 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x33 || securityAccessDenied | This response code indicates that the requested action will not be taken because the server's security strategy has not been satisfied by the client. The server shall send this response code if one of the following cases occur: * the test conditions of the server are not met, * the required message sequence e.g. DiagnosticSessionControl, securityAccess is not met, * the client has sent a request message which requires an unlocked server. <br>Beside the mandatory use of this negative response code as specified in the applicable services within this standard, this negative response code can also be used for any case where security is required and is not yet granted to perform the required service. |- | 0x34 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x35 || invalidKey | This response code indicates that the server has not given security access because the key sent by the client did not match with the key in the server's memory. This counts as an attempt to gain security. The server shall remain locked and increment its internal securityAccessFailed counter. |- | 0x36 || exceedNumberOfAttempts | This response code indicates that the requested action will not be taken because the client has unsuccessfully attempted to gain security access more times than the server's security strategy will allow. |- | 0x37 || requiredTimeDelayNotExpired | This response code indicates that the requested action will not be taken because the client's latest attempt to gain security access was initiated before the server's required timeout period had elapsed. |- | 0x38 - 0x4F || reservedByExtendedDataLinkSecurityDocument | This range of values is reserved by ISO 15764 Extended data link security. |- | 0x50 - 0x6F || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x70 || uploadDownloadNotAccepted | This response code indicates that an attempt to upload/download to a server's memory cannot be accomplished due to some fault conditions. |- | 0x71 || transferDataSuspended | This response code indicates that a data transfer operation was halted due to some fault. The active transferData sequence shall be aborted. |- | 0x72 || generalProgrammingFailure | This response code indicates that the server detected an error when erasing or programming a memory location in the permanent memory device (e.g. Flash Memory). |- | 0x73 || wrongBlockSequenceCounter | This response code indicates that the server detected an error in the sequence of blockSequenceCounter values. Note that the repetition of a TransferData request message with a blockSequenceCounter equal to the one included in the previous TransferData request message shall be accepted by the server. |- | 0x74 - 0x77 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x78 || requestCorrectlyReceived-ResponsePending | This response code indicates that the request message was received correctly, and that all parameters in the request message were valid, but the action to be performed is not yet completed and the server is not yet ready to receive another request. As soon as the requested service has been completed, the server shall send a positive response message or negative response message with a response code different from this. The negative response message with this response code may be repeated by the server until the requested service is completed and the final response message is sent. This response code might impact the application layer timing parameter values. The detailed specification shall be included in the data link specific implementation document. This response code shall only be used in a negative response message if the server will not be able to receive further request messages from the client while completing the requested diagnostic service. When this response code is used, the server shall always send a final response (positive or negative) independent of the suppressPosRspMsgIndicationBit value. A typical example where this response code may be used is when the client has sent a request message, which includes data to be programmed or erased in flash memory of the server. If the programming/erasing routine (usually executed out of RAM) is not able to support serial communication while writing to the flash memory the server shall send a negative response message with this response code. This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- | 0x79 - 0x7D || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x7E || subFunctionNotSupportedInActiveSession | This response code indicates that the requested action will not be taken because the server does not support the requested sub-function in the session currently active. Within the programmingSession negative response code 0x12 (subFunctionNotSupported) may optionally be reported instead of negative response code 0x7F (subFunctionNotSupportedInActiveSession). This response code shall only be used when the requested sub-function is known to be supported in another session, otherwise response code 0x12 (subFunctionNotSupported) shall be used. This response code shall be supported by each diagnostic service with a sub-function parameter, if not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- | 0x7F || serviceNotSupportedInActiveSession | This response code indicates that the requested action will not be taken because the server does not support the requested service in the session currently active. This response code shall only be used when the requested service is known to be supported in another session, otherwise response code 0x11 (serviceNotSupported) shall be used. This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- | 0x80 || ISOSAEReserved | This range of values is reserved for future definition. |- | 0x81 || rpmTooHigh | This response code indicates that the requested action will not be taken because the server prerequisite condition for RPM is not met (current RPM is above a pre-programmed maximum threshold). |- | 0x82 || rpmTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for RPM is not met (current RPM is below a pre-programmed minimum threshold). |- | 0x83 || engineIsRunning | This is required for those actuator tests which cannot be actuated while the Engine is running. This is different from RPM too high negative response and needs to be allowed. |- | 0x84 || engineIsNotRunning | This is required for those actuator tests which cannot be actuated unless the Engine is running. This is different from RPM too low negative response, and needs to be allowed. |- | 0x85 || engineRunTimeTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for engine run time is not met (current engine run time is below a preprogrammed limit). |- | 0x86 || temperatureTooHigh | This response code indicates that the requested action will not be taken because the server prerequisite condition for temperature is not met (current temperature is above a preprogrammed maximum threshold). |- | 0x87 || temperatureTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for temperature is not met (current temperature is below a preprogrammed minimum threshold). |- | 0x88 || vehicleSpeedTooHigh | This response code indicates that the requested action will not be taken because the server prerequisite condition for vehicle speed is not met (current VS is above a pre-programmed maximum threshold). |- | 0x89 || vehicleSpeedTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for vehicle speed is not met (current VS is below a pre-programmed minimum threshold). |- | 0x8A || throttle/PedalTooHigh | This response code indicates that the requested action will not be taken because the server prerequisite condition for throttle/pedal position is not met (current TP/APP is above a preprogrammed maximum threshold). |- | 0x8B || throttle/PedalTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for throttle/pedal position is not met (current TP/APP is below a preprogrammed minimum threshold). |- | 0x8C || transmissionRangeNotInNeutral | This response code indicates that the requested action will not be taken because the server prerequisite condition for being in neutral is not met (current transmission range is not in neutral). |- | 0x8D || transmissionRangeNotInGear | This response code indicates that the requested action will not be taken because the server prerequisite condition for being in gear is not met (current transmission range is not in gear). |- | 0x8E || ISOSAEReserved | This range of values is reserved by this document for future definition. |- | 0x8F || brakeSwitch(es)NotClosed (Brake Pedal not pressed or not applied) | For safety reasons, this is required for certain tests before it begins, and must be maintained for the entire duration of the test. |- | 0x90 || shifterLeverNotInPark | For safety reasons, this is required for certain tests before it begins, and must be maintained for the entire duration of the test. |- | 0x91 || torqueConverterClutchLocked | This response code indicates that the requested action will not be taken because the server prerequisite condition for torque converter clutch is not met (current TCC status above a preprogrammed limit or locked). |- | 0x92 || voltageTooHigh | This response code indicates that the requested action will not be taken because the server prerequisite condition for voltage at the primary pin of the server (ECU) is not met (current voltage is above a pre-programmed maximum threshold). |- | 0x93 || voltageTooLow | This response code indicates that the requested action will not be taken because the server prerequisite condition for voltage at the primary pin of the server (ECU) is not met (current voltage is below a pre-programmed maximum threshold). |- | 0x94 - 0xFE || reservedForSpecificConditionsNotCorrect | This range of values is reserved for future definition. |- | 0xFF || ISOSAEReserved | This range of values is reserved for future definition. |} 731784a2713f5e76c2301395f03e385ed0cec1c4 0 841 1292 2014-09-25T12:19:07Z Oliver 1 Created page with "Microcontroller Open System Architecture is the [http://vector.com Vector] AUTOSAR solution" wikitext text/x-wiki Microcontroller Open System Architecture is the [http://vector.com Vector] AUTOSAR solution 1933d8996d1b5efb0544bdfb9260653974fb2d39 0 449 1293 847 2014-09-25T23:40:14Z Oliver 1 wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Basic Software Module#Complex Drivers|Complex Device Drivers]] = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[Memory Abstraction Interface]] (MemIf) * [[Flash EEPROM Emulation]] (Fee) * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = The Complex Device [[Driver]] (CDD) generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with [[Software Component]]s in specific ways and can also interact directly with other Basic Software Modules. The Complex Drivers Layer spans from the hardware to the [[RTE]]. It provides the possibility to integrate special purpose functionality, e.g. drivers for specific devices: * which are not specified within AUTOSAR, * with very high timing constrains or * for migration purposes etc. An [[Atomic Software Component]] that on one side interfaces with the [[VFB]] and on the other side directly accesses [[Peripheral Hardware]] and/or [[ECU-Abstraction]] and/or [[MCAL]]. Complex Driver can be accessed via [[AUTOSAR Interface]]s and/or directly by Basic Software Modules (BSWM). This [[SW]] situated below the AUTOSAR [[RTE]]. This software in general is not re-locatable. ef94d093e23f21363d11b756d9016a22fb67f866 0 842 1294 2014-09-28T19:02:47Z Oliver 1 Created page with "The [[port]] for receiving (or sending) a [[mode]] switch notification. For this purpose, a [[mode switch]] port is typed by a [[Mode Switch Interface]]." wikitext text/x-wiki The [[port]] for receiving (or sending) a [[mode]] switch notification. For this purpose, a [[mode switch]] port is typed by a [[Mode Switch Interface]]. 152211a3ec9bd4dcc7d492d06b57c6cca089026b 1298 1294 2014-09-28T19:06:22Z Oliver 1 wikitext text/x-wiki The [[port]] for receiving (or sending) a [[mode switch notification]]. For this purpose, a [[mode switch]] port is typed by a [[Mode Switch Interface]]. b35cf10adab2323ac1eac587b5a944f434d42625 0 843 1295 2014-09-28T19:03:48Z Oliver 1 Created page with "An [[AUTOSAR]] [[SW-C]] or AUTOSAR [[Basic Software Module]] that depends on modes by ModeDisablingDependency, SwcModeSwitchEvent, BswModeSwitchEvent, or simply by reading the..." wikitext text/x-wiki An [[AUTOSAR]] [[SW-C]] or AUTOSAR [[Basic Software Module]] that depends on modes by ModeDisablingDependency, SwcModeSwitchEvent, BswModeSwitchEvent, or simply by reading the current state of a [[mode]] is called a mode user. A mode user is defined by having a require [[mode switch port]] or a requiredModeGroup ModeDeclarationGroupPrototype. 24879d50fd06443d71bddb1af4cef154d26b164f 1303 1295 2014-09-28T19:11:41Z Oliver 1 wikitext text/x-wiki An [[AUTOSAR]] [[SW-C]] or AUTOSAR [[Basic Software Module]] that depends on modes by [[ModeDisablingDependency]], SwcModeSwitchEvent, BswModeSwitchEvent, or simply by reading the current state of a [[mode]] is called a mode user. A mode user is defined by having a require [[mode switch port]] or a requiredModeGroup ModeDeclarationGroupPrototype. 3cd000d107ddcb3ebc56da957f3dc93ec3394e38 0 844 1296 2014-09-28T19:05:01Z Oliver 1 Created page with "Entering and leaving [[mode]]s is initiated by a mode manager. A mode manager is defined by having a provide [[mode switch port]] or a providedModeGroup ModeDeclarationGroupPr..." wikitext text/x-wiki Entering and leaving [[mode]]s is initiated by a mode manager. A mode manager is defined by having a provide [[mode switch port]] or a providedModeGroup ModeDeclarationGroupPrototype. A mode manager might be either an application mode manager or a [[Basic Software Module]] that provides a service including mode switches, like the [[ECU State Manager]]. 6c11edf916b797748a12f47bd558b68c6c7357cb 0 845 1297 2014-09-28T19:05:41Z Oliver 1 Created page with "An application [[mode]] manager is an [[AUTOSAR]] [[Software Component]] that provides the service of switching modes. The modes of an application mode manager do not have to ..." wikitext text/x-wiki An application [[mode]] manager is an [[AUTOSAR]] [[Software Component]] that provides the service of switching modes. The modes of an application mode manager do not have to be standardized. 1e94255f37c684d578447a504c6f276ab950d334 0 846 1299 2014-09-28T19:07:00Z Oliver 1 Created page with "The communication of a [[mode switch]] from the [[mode manager]] to the mode user using either the ModeSwitchInterface or providedModeGroup and requiredModeGroup ModeDeclarati..." wikitext text/x-wiki The communication of a [[mode switch]] from the [[mode manager]] to the mode user using either the ModeSwitchInterface or providedModeGroup and requiredModeGroup ModeDeclarationGroupPrototypes [[Link title]]is called mode switch notification. 36ac5af75aa5c6db97afcddbacd95d7455bd1f22 0 847 1300 2014-09-28T19:08:29Z Oliver 1 Created page with "The instances of [[mode]] machines or ModeDeclaration-Groups are defined by the ModeDeclarationGroup-Prototypes of the [[mode manager]]s. Since a [[mode switch]] is not execut..." wikitext text/x-wiki The instances of [[mode]] machines or ModeDeclaration-Groups are defined by the ModeDeclarationGroup-Prototypes of the [[mode manager]]s. Since a [[mode switch]] is not executed instantaneously, the [[RTE]] or [[Basic Software Scheduler]] has to maintain it’s own states. For each mode manager’s ModeDeclarationGroupPrototype, RTE or Basic Software Scheduler has one [[state machine]]. This state machine is called mode machine instance. For all mode users of the same mode manager’s ModeDeclarationGroupPrototype, RTE and Basic Software Scheduler uses the same mode machine instance. 3537f1c9f5ab07358f36517f5ab7cfafb9611e00 0 848 1301 2014-09-28T19:09:52Z Oliver 1 Created page with "A common mode machine instance is a special [[mode machine instance]] shared by [[BSW Module]]s and [[SW-C]]s: The [[RTE Generator]] creates only one [[mode machine]] instance..." wikitext text/x-wiki A common mode machine instance is a special [[mode machine instance]] shared by [[BSW Module]]s and [[SW-C]]s: The [[RTE Generator]] creates only one [[mode machine]] instance if a ModeDeclarationGroupPrototype instantiated in a [[port]] of a software-component is synchronized (synchronizedModeGroup of a SwcBswMapping) with a providedModeGroup ModeDeclarationGroupPrototype of a Basic Software Module instance. The related mode machine instance is called common mode machine instance. 72450e1d48b4a136e06b403089508477a1af1980 0 849 1302 2014-09-28T19:11:18Z Oliver 1 Created page with "An [[RTE Event]] and [[BSW Event]] that starts a [[Runnable Entity]] respectively a [[Basic Software Schedulable Entity]] can contain a disabledInMode association which refere..." wikitext text/x-wiki An [[RTE Event]] and [[BSW Event]] that starts a [[Runnable Entity]] respectively a [[Basic Software Schedulable Entity]] can contain a disabledInMode association which references a ModeDeclaration. 24a7faceb486c601c75fd7ce6af1133c55016e0a 0 850 1304 2014-09-28T19:12:50Z Oliver 1 Created page with "A mode disabling dependent [[Runnable Entity]] or a [[Basic Software Schedulable Entity]] is triggered by an [[RTE Event]] respectively a [[BSW Event]] with a ModeDisablingDep..." wikitext text/x-wiki A mode disabling dependent [[Runnable Entity]] or a [[Basic Software Schedulable Entity]] is triggered by an [[RTE Event]] respectively a [[BSW Event]] with a ModeDisablingDependency. [[RTE]] and [[Basic Software Scheduler]] prevent the start of those Runnable Entity or Basic Software Schedulable Entity by the RTEEvent / BswEvent, when the corresponding mode disabling is active. 14ccada46ee8e05b75a3e6980e94a114fe48bb3a 1305 1304 2014-09-28T19:13:29Z Oliver 1 wikitext text/x-wiki A [[mode disabling]] dependent [[Runnable Entity]] or a [[Basic Software Schedulable Entity]] is triggered by an [[RTE Event]] respectively a [[BSW Event]] with a ModeDisablingDependency. [[RTE]] and [[Basic Software Scheduler]] prevent the start of those Runnable Entity or Basic Software Schedulable Entity by the RTEEvent / BswEvent, when the corresponding mode disabling is active. 8e3d33cb85afdca9e1cbbd31f5d4d194a5d6cc53 0 851 1306 2014-09-28T19:14:08Z Oliver 1 Created page with "When a [[mode]] disabling is active, [[RTE]] and [[Basic Software Scheduler]] disables the start of mode disabling dependent ExecutableEntitys. The mode disabling is active du..." wikitext text/x-wiki When a [[mode]] disabling is active, [[RTE]] and [[Basic Software Scheduler]] disables the start of mode disabling dependent ExecutableEntitys. The mode disabling is active during the mode that is referenced in the mode disabling dependency and during the transitions that enter and leave this mode. a7cdd7e103e74d272ef9881862d600625b520ed2 0 852 1307 2014-10-01T22:53:53Z Oliver 1 Created page with "AUTOSAR Tool Platform User Group see [https://www.artop.org/organization]" wikitext text/x-wiki AUTOSAR Tool Platform User Group see [https://www.artop.org/organization] a4ed506bcd72446ebf9cf8731909426037500d88 0 698 1308 1110 2014-10-01T23:05:41Z Oliver 1 wikitext text/x-wiki #REDIRECT [[Electronic Control Unit|ABS]] 7dc8cd316c59b14562a583ff563b3eb23f90c0cd 1310 1308 2014-10-01T23:06:25Z Oliver 1 Redirected page to [[Electronic Control Unit#ABS]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#ABS]] 248964cb9c3ecb77c1b20f6a9872ec2cb9e22c2d 0 700 1309 1114 2014-10-01T23:05:56Z Oliver 1 Redirected page to [[Electronic Control Unit]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit|ACC]] 6fdb90d2f6995bc4942e872ed8c2310ca46a2430 1311 1309 2014-10-01T23:06:47Z Oliver 1 Redirected page to [[Electronic Control Unit#ACC]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#ACC]] 48771af3de1bcd71bf704593740d61dabaab72c0 0 853 1312 2014-10-01T23:07:16Z Oliver 1 Created page with "Arithmetic and logic unit" wikitext text/x-wiki Arithmetic and logic unit 9105b426f2682b119bf1b965b9fae164c80a531b 0 28 1313 31 2014-10-01T23:07:38Z Oliver 1 Redirected page to [[Controller Area Network]] wikitext text/x-wiki #REDIRECT [[Controller Area Network]] 4e7ea12f8ad7ce27ba8cffdc3919328ae06ecb87 0 854 1314 2014-10-01T23:08:24Z Oliver 1 Created page with "Carrier Sense Multiple Access" wikitext text/x-wiki Carrier Sense Multiple Access 516bdbf19b7085404eaa682474ca91d601493775 0 855 1315 2014-10-01T23:08:55Z Oliver 1 Created page with "Carrier Sense Multiple Access / Collision Avoidance" wikitext text/x-wiki Carrier Sense Multiple Access / Collision Avoidance 735c70ecd4007a096f49008f73748325b5560c2c 1316 1315 2014-10-01T23:09:05Z Oliver 1 wikitext text/x-wiki [[Carrier Sense Multiple Access]] / Collision Avoidance 837fcdadd881be249dad14fda454a66d24a4a137 0 856 1317 2014-10-01T23:09:21Z Oliver 1 Created page with "[[Carrier Sense Multiple Access]] / Collision Detection" wikitext text/x-wiki [[Carrier Sense Multiple Access]] / Collision Detection 25a1602da9185a29fa22a0224c9aea02498ee060 0 857 1318 2014-10-01T23:09:34Z Oliver 1 Created page with "Direct Memory Access" wikitext text/x-wiki Direct Memory Access a8ea26e5222ff6509f77e66abe8fe8013ff2ca93 0 858 1319 2014-10-01T23:09:54Z Oliver 1 Created page with "Dynamic [[RAM]]" wikitext text/x-wiki Dynamic [[RAM]] 0474d300ea3bbd21910f83d60f3d1fe697bb571b 0 665 1320 1112 2014-10-01T23:11:16Z Oliver 1 Redirected page to [[Electronic Control Unit#ESP]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#ESP]] 1c3896f9890220f7859559d3027dbbacb1a828c9 0 859 1321 2014-10-01T23:11:52Z Oliver 1 Created page with "Fault Tree Analysis" wikitext text/x-wiki Fault Tree Analysis bb287d76b1e8402f5d0daa7f00912042b2d73cac 0 860 1322 2014-10-01T23:12:38Z Oliver 1 Created page with "Line Of Visibility" wikitext text/x-wiki Line Of Visibility 226fdb720e9768ffdd8f95f477301e408b1163ad 0 861 1323 2014-10-01T23:13:12Z Oliver 1 Redirected page to [[Mean Time To Repair]] wikitext text/x-wiki #REDIRECT [[Mean Time To Repair]] ca2aa5d573e0e4fdcbb30373aa782172d1337ddb 0 862 1324 2014-10-01T23:13:59Z Oliver 1 Created page with "Parts Per Million = 1/1000000" wikitext text/x-wiki Parts Per Million = 1/1000000 a86298d45655a0ad156cd9564829adf6ab08943f 0 863 1325 2014-10-01T23:14:20Z Oliver 1 Created page with "Programmable [[ROM]]" wikitext text/x-wiki Programmable [[ROM]] 1e6d88e6c5a643a7a8bd157574aeb144cba2c464 0 699 1326 1111 2014-10-01T23:14:46Z Oliver 1 Redirected page to [[Electronic Control Unit#SBC]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#SBC]] 3319635a08052fbd4d20f4baf226c773e7cd3414 0 864 1327 2014-10-01T23:15:21Z Oliver 1 Created page with "Static [[RAM]]" wikitext text/x-wiki Static [[RAM]] c441a386f51a3975f9a60f6fe41729e5c7c56b2e 0 865 1328 2014-10-01T23:15:46Z Oliver 1 Redirected page to [[Electronic Control Unit#TCS]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#TCS]] a47d0ada8e84832e6c759f7b866a2c72e7cac4e2 0 159 1329 1232 2014-10-01T23:16:10Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ESP || Electronic Stability Program || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |- |LSM || Light Switch Module || |- |RSM || Rain Sensor Module || |- |TBM || Trailer Brake Module || |- |TRM || Trailer Module || |- |AFS || Active Front Steering<br>Advanced Frontlighting System || |- |TCS || Traction Control System || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 2f631e92518684612c55db3f96911c34eb7b7dd9 1352 1329 2014-10-14T09:38:44Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ESP || Electronic Stability Program || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |- |LSM || Light Switch Module || |- |RSM || Rain Sensor Module || |- |TBM || Trailer Brake Module || |- |TRM || Trailer Module || |- |AFS || Active Front Steering<br>Advanced Frontlighting System || |- |TCS || Traction Control System || |- |ACC || Adaptive Cruise Control || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 944cd9f093013438e47eed6131afef57f1454d65 0 866 1330 2014-10-01T23:16:31Z Oliver 1 Created page with "Time Division Multiple Access" wikitext text/x-wiki Time Division Multiple Access eeabd042b5d1963c1910b1215ba0e45da0753eb4 0 867 1331 2014-10-01T23:16:46Z Oliver 1 Created page with "Time To [[Failure]]" wikitext text/x-wiki Time To [[Failure]] c2b836689d1cfbaef7a9fc4a808e316a11df34f1 0 868 1332 2014-10-01T23:17:43Z Oliver 1 Created page with "Verband der Automobilindustrie. See [http://www.vda.de/de/index.html]" wikitext text/x-wiki Verband der Automobilindustrie. See [http://www.vda.de/de/index.html] 529c3be10eb9d16f79d1926486c0d0f241d75935 0 869 1333 2014-10-02T09:21:56Z Oliver 1 Created page with "Support of the [[AUTOSAR meta-model]] for the pre-definition of model elements taken as the basis for further modeling. These pre-defintions are called blueprints." wikitext text/x-wiki Support of the [[AUTOSAR meta-model]] for the pre-definition of model elements taken as the basis for further modeling. These pre-defintions are called blueprints. eb7be5bcd6f3f7a0a937b45f24c395d8e103f01a 1340 1333 2014-10-02T09:48:18Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Support of the [[AUTOSAR meta-model]] for the pre-definition of model elements taken as the basis for further modeling. These pre-defintions are called blueprints. This is a model from which other models can be derived by copy and refinement. Note that in contrast to meta model resp. types, this process is not an instantiation. 934ec6e29ce282243a92ae267657a09431c42094 0 870 1334 2014-10-02T09:26:22Z Oliver 1 Redirected page to [[Standard Module Definition]] wikitext text/x-wiki #REDIRECT [[Standard Module Definition]] 2859b4a96da7c1d1e74128a2a9272b6917cc089a 0 871 1335 2014-10-02T09:27:02Z Oliver 1 Redirected page to [[Vendor Specific Module Defintion]] wikitext text/x-wiki #REDIRECT [[Vendor Specific Module Defintion]] 3c4b1568114eb3d8c31340ff8f89c0e589570d82 0 872 1336 2014-10-02T09:39:30Z Oliver 1 Created page with "This is an [[UML]]2.0 model that defines the language for describing [[AUTOSAR system]]s. The AUTOSAR meta-model is an UML representation of the [[AUTOSAR template]]s. UML2.0..." wikitext text/x-wiki This is an [[UML]]2.0 model that defines the language for describing [[AUTOSAR system]]s. The AUTOSAR meta-model is an UML representation of the [[AUTOSAR template]]s. UML2.0 class diagrams are used to describe the attributes and their interrelationships. Stereotypes, UML tags and OCL expressions (object constraint language) are used for defining specific semantics and constraints. 38b2746531ff558128038cfa6db1c6951ea92db2 1356 1336 2014-10-15T10:21:07Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] This is an [[UML]]2.0 model that defines the language for describing [[AUTOSAR system]]s. The AUTOSAR meta-model is an UML representation of the [[AUTOSAR template]]s. UML2.0 class diagrams are used to describe the attributes and their interrelationships. Stereotypes, UML tags and OCL expressions (object constraint language) are used for defining specific semantics and constraints. e53359bc8f802aabe60dcd79580b818cf94fec24 0 180 1337 401 2014-10-02T09:41:18Z Oliver 1 wikitext text/x-wiki The term feature is commonly used in the [[software tool]] community to describe characteristics (functionality) of the software. In AUTOSAR a feature is represented by one or many meta classes and their attributes in the [[AUTOSAR meta-model]]. Features are used to implement [[use case]]s such that a single use case requires one or more features for implementation. f3cb9eb0d1cce4a7b35fbd3114ff0233baae7b08 0 873 1338 2014-10-02T09:46:58Z Oliver 1 Created page with "[[Category:AUTOSAR]] The term "Template" is used in [[AUTOSAR]] to describe the format different kinds of descriptions. The term [[template]] comes from the idea, that AUTOSAR..." wikitext text/x-wiki [[Category:AUTOSAR]] The term "Template" is used in [[AUTOSAR]] to describe the format different kinds of descriptions. The term [[template]] comes from the idea, that AUTOSAR defines a kind of form which shall be filled out in order to describe a model. The filled form is then called the description. 260ba545d93dd33806b923a97bf983bf1ed2571e 0 119 1339 1091 2014-10-02T09:47:28Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[AUTOSAR]] XML Schema is an [[XML]] language definition for exchanging [[AUTOSAR model]]s and descriptions. It is a W3C XML schema that defines the language for exchanging AUTOSAR models. This Schema is derived from the [[AUTOSAR metamodel]]. The AUTOSAR XML Schema defines the AUTOSAR data exchange format. This is a W3C XML schema that defines the language for exchanging AUTOSAR models. This Schema is derived from the AUTOSAR meta model. The AUTOSAR XML Schema defines the AUTOSAR data exchange format. 6f38d88fe1c377d1bd826959c2145ddd1ff711dc 0 874 1341 2014-10-02T10:04:38Z Oliver 1 Created page with "[[Category:AUTOSAR]] [[Software Component]] template" wikitext text/x-wiki [[Category:AUTOSAR]] [[Software Component]] template 43b5141dcbeeb50c250627b27536238d5eda73ef 0 875 1342 2014-10-02T10:04:58Z Oliver 1 Created page with "[[Category:AUTOSAR]] System template" wikitext text/x-wiki [[Category:AUTOSAR]] System template c2db657be45107821feea6de94df05e5d34fc223 0 876 1343 2014-10-02T10:05:19Z Oliver 1 Created page with "XML Schema Definition" wikitext text/x-wiki XML Schema Definition 925695fafdb9b3abbbf523098a555d2593502e83 0 877 1344 2014-10-02T10:05:58Z Oliver 1 Redirected page to [[DoIP]] wikitext text/x-wiki #REDIRECT [[DoIP]] 246889377525259b8e245f4c1108fe295803e037 0 352 1345 410 2014-10-02T12:47:04Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A [[variation]] point indicates that a [[property]] is subject to variation. Furthermore, it is associated with a condition and a binding time which define the [[system]] context for the selection / setting of a concrete [[variant]]. 94c7c500510d88576e65392f4f6e7ebac84764e9 0 878 1346 2014-10-02T12:47:49Z Oliver 1 Created page with "[[Category:AUTOSAR]] The variation definition time determines the step in the [[methodology]] at which the [[variation point]]s are defined." wikitext text/x-wiki [[Category:AUTOSAR]] The variation definition time determines the step in the [[methodology]] at which the [[variation point]]s are defined. 96cede68e8afd0d21706f5e9684c76d80507404b 0 350 1347 408 2014-10-02T12:48:14Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The variation binding time determines the step in the [[methodology]] at which the variability given by a set of variable properties is resolved. 0dd5caf639ee5e59dd8f7258a8a8447c21a571cc 0 349 1348 407 2014-10-02T12:48:44Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A [[variant]] is the result of a variation binding process that resolves the variability of the [[system]] by assigning particular values/selections to all the system’s properties. 579099498aff0eba945e2e4a17fca12ed58e1a55 0 347 1349 405 2014-10-02T12:49:38Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A system variant is a concrete realization of a [[system]], so that all its properties have been set respectively selected. The [[software system]] has no variability anymore with respect to the binding time. 08a995e109105e2ecbadc0801a7bdd01847d3852 0 346 1350 404 2014-10-02T12:50:01Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Variability of a [[system]] is its quality to describe a set of [[variant]]s. These variants are characterized by variant specific property settings and / or selections. 73bdf30d64365a3ec0031db59bd394706ea8aee3 0 879 1351 2014-10-14T07:39:35Z Oliver 1 Created page with "Advanced Driver Assistance Systems" wikitext text/x-wiki Advanced Driver Assistance Systems f1877a1f8a4a21db7b00e569d9cecd72704907f0 0 449 1353 1293 2014-10-15T10:11:34Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] for BSW Mode Manager see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Basic Software Module#Complex Drivers|Complex Device Drivers]] = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[Memory Abstraction Interface]] (MemIf) * [[Flash EEPROM Emulation]] (Fee) * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) = Complex Drivers = The Complex Device [[Driver]] (CDD) generalizes the [[ECU-abstraction component]]. It can define [[port]]s to interact with [[Software Component]]s in specific ways and can also interact directly with other Basic Software Modules. The Complex Drivers Layer spans from the hardware to the [[RTE]]. It provides the possibility to integrate special purpose functionality, e.g. drivers for specific devices: * which are not specified within AUTOSAR, * with very high timing constrains or * for migration purposes etc. An [[Atomic Software Component]] that on one side interfaces with the [[VFB]] and on the other side directly accesses [[Peripheral Hardware]] and/or [[ECU-Abstraction]] and/or [[MCAL]]. Complex Driver can be accessed via [[AUTOSAR Interface]]s and/or directly by Basic Software Modules (BSWM). This [[SW]] situated below the AUTOSAR [[RTE]]. This software in general is not re-locatable. e08eb0eed224e69b2569c0d907b40cd1b6bf4ec9 0 880 1354 2014-10-15T10:11:38Z Oliver 1 Redirected page to [[Virtual Function Cluster]] wikitext text/x-wiki #REDIRECT [[Virtual Function Cluster]] 24f21513fecec4a59a1214f60863faa9d88678b7 0 881 1355 2014-10-15T10:12:57Z Oliver 1 Created page with "[[Category:AUTOSAR]] On the level of the [[Software Component Template]], [[Partial Networking]] is supported by means of the concept of a "Virtual Function Cluster" (VFC). It..." wikitext text/x-wiki [[Category:AUTOSAR]] On the level of the [[Software Component Template]], [[Partial Networking]] is supported by means of the concept of a "Virtual Function Cluster" (VFC). It groups all ommunication on the [[VFB]] with respect to a given function. eac36ec236a34ab1ae817d533cb8405d8e960fff 0 560 1357 819 2014-10-15T10:21:29Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The BSW Mode [[Manager]] (BswM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === d23f44feabc55acdb19c20a0fc209421bf145f64 0 559 1358 818 2014-10-15T10:21:49Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The COM [[Manager]] (ComM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 1a0625e7bedaf6987c46a0f19cd208fe11a3b0bd 0 677 1359 1049 2014-10-15T10:22:16Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A [[Port]] can ‘override’ attributes of the [[Port Interface]] and add attributes by defining its communication specification declarations (ComSpec / com spec). 01238ed9ae5cce8a5b260c94553b09e293818d0b 0 389 1360 480 2014-10-15T10:22:21Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A Software Composition Component encapsulates a collaboration of [[Software Component]]s (SW-C), thereby hiding detail and allowing the creation of higher abstraction levels. Through [[Delegation Connectors]] a Composition explicitly specifies, which [[Port]]s of the internal components are visible from the outside. AUTOSAR Compositions are a type of [[Component]]s, e.g. they can be part of further compositions. The usage of a [[Component Type]] within a composition is called a [[Prototype]]. A Composition Software Component encapsulates a collaboration of Software Components, thereby hiding detail and allowing the creation of higher abstraction levels. Through delegation connectors a composition software component explicitly specifies, which ports of the internal components are visible from the outside. Composition Software Components are a specialized type of Software Components, e.g. they can be part of further Composition Software Components. e9ff0b182efea3d8dd02a8590fdd16c463e11668 0 433 1361 555 2014-10-15T10:22:37Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Contract Phase are the files generated by the [[RTE-Generator]] for [[SW-C]] independent of the [[BSWM]]. It is used to enable the SW-C supplier to start implementing code even before the BSWM are configured. The Contract Phase also defines the [[service needs]] etc. of the specific SW-C. 2e97c2f83fe9731e7c4a27e7c28525dbec830ee4 0 561 1362 820 2014-10-15T10:22:39Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Crypto Service [[Manager]] (Csm) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 981eed18c65155d474d6dcf440c7f59e745c3c8e 0 541 1363 795 2014-10-15T10:22:53Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The DIO [[Driver]] (Dio) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 831435ee5e9fb1e01c1be93caf12f9c01234cabf 0 162 1364 759 2014-10-15T10:23:18Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Development Error Tracer (Det) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Development Error Tracer module to which development errors are reported. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f478c53f0271ebf685958702aaf62468c8bd1581 0 539 1365 868 2014-10-15T10:23:21Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Diagnostic Communication [[Manager]] (Dcm) is a [[Basic Software Module]] of the [[Communication Services]]. It is in charge of the communication path and execution of [[diagnostic service]] resulting in the processing of [[diagnostic requests]] from an external [[tester]] or onboard test system. It forwards requests coming from an external diagnostic scan tool and is further responsible for assembly of response messages ([[DTC]], status information, etc.) which will be transferred to the external diagnostic scan tool afterwards. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f8a76ed8762003d0e720f4fe206825624119861c 0 448 1366 885 2014-10-15T10:23:25Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the [[diagnostic event]]s detected by [[diagnostic monitor]]s in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function === [[Standardized Interface]] === * Dem_ReportErrorStatus * Dem_GetVersionInfo === [[Container]]s and configuration parameters === Format: ''Container / Parameter {Multiplicity; Type; ConfigurationClass; Range}'' ''Description'' ==== DemConfigSet ==== Multiplicity:=1 ==== DemGeneral ==== Multiplicity:=1 DemGeneral/'''DemAgingCycleCounterProcessing''' {1; [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the aging counter is calculated Dem-internally or provided via [[Dem_SetAgingCycleCounterValue]]. * DEM_PROCESS_AGINGCTR_EXTERN: based on [[API]] [[Dem_SetAgingCycleCounterValue]] * DEM_PROCESS_AGINGCTR_INTERN: based on reported cycle states DemGeneral/'''DemBswErrorBufferSize''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of elements in buffer for handling of BSW errors. DemGeneral/'''DemClearDTCBehavior''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} Defines the clearing process of diagnostic information for volatile and [[non-volatile memory]] and the positive response handling for the [[Dcm]] module. * DEM_CLRRESP_NONVOLATILE_FINISH: Return DEM_CLEAR_OK after volatile and non-volatile event memory data cleared. * DEM_CLRRESP_NONVOLATILE_TRIGGER: Return DEM_CLEAR_OK after volatile event memory data cleared and non-volatile event memory clearing is triggered * DEM_CLRRESP_VOLATILE: Return DEM_CLEAR_OK after volatile event memory data cleared DemGeneral/'''DemDTCSuppressionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for [[DTC]] suppression is enabled or not. * TRUE: DTC suppression support is enabled * FALSE: DTC suppression support is disabled DemGeneral/'''DemDebounceCounterBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for counter based debouncing is enabled or not. * TRUE: counter based debouncing support is enabled * FALSE: counter based debouncing support is disabled DemGeneral/'''DemDebounceTimeBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for time based debouncing is enabled or not. * TRUE: time based debouncing support is enabled * FALSE: time based debouncing support is disabled DemGeneral/'''DemDevErrorDetect''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the Development Error Detection and Notification. * TRUE: Development Error Detection and Notification activated * FALSE: DevelopmentError Detection and Notification deactivated DemGeneral/'''DemDtcStatusAvailabilityMask''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Mask for the supported [[DTC]] status bits by the Dem. This mask is used by [[UDS]] service 0x19. DemGeneral/'''DemEnableConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for enable conditions is enabled or not. * TRUE: support for enable conditions is enabled * FALSE: support for enable conditions is disabled DemGeneral/'''DemEventCombinationSupport''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of event combination supported by the Dem. * DEM_EVCOMB_DISABLED: No event combination supported * DEM_EVCOMB_TYPE1: Event combination Type 1 enabled * DEM_EVCOMB_TYPE2: Event combination Type 2 enabled DemGeneral/'''DemEventDisplacementSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for event displacement is enabled or not. * TRUE: event displacement support is enabled * FALSE: event displacement support is disabled DemGeneral/'''DemExtendedDataCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the extended data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of extended data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of extended data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemFreezeFrameCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the freeze frame data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of freeze frame data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of freeze frame data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemHeaderFileInclusion''' {0..*, [[EcucStringParamDef|String]]; [[Pre-compile time|Pre]]} Name of the header file(s) to be included by the Dem module containing the used C-[[callback]] declarations. DemGeneral/'''DemImmediateNvStorageLimit''' {0..1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} This parameter defines the maximum number of occurrences, a specific event memory entry is allowed, to be stored in [[NVRAM]] immediately (refer to [[DemImmediateNvStorage]]). DemGeneral/'''DemMaxNumberEventEntryMirror''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[mirror memory]]. DemGeneral/'''DemMaxNumberEventEntryPermanent''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[permanent memory]]. The assignment of an event to this memory type is dynamic and used for emission-related events only. DemGeneral/'''DemMaxNumberEventEntryPrimary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} Maximum number of events which can be stored in the [[primary memory]]. DemGeneral/'''DemMaxNumberEventEntrySecondary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[secondary memory]]. DemGeneral/'''DemMaxNumberPrestoredFF''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Defines the maximum number for pre-stored [[freeze frame]]s. If set to 0, then freeze frame pre-storage is not supported by the [[ECU]]. DemGeneral/'''DemOBDSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines whether [[OBD]] is supported or not. DemGeneral/'''DemOccurrenceCounterProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines the consideration of the fault confirmation process for the occurrence counter. For [[OBD]] and mixed systems (OBD/non OBD, refer to [[DemOBDSupport]]) the fault confirmation process must not be considered. * DEM_PROCESS_OCCCTR_CDTC: the occurrence counter is triggered by the TestFailed bit only, but the fault confirmation is not considered * DEM_PROCESS_OCCCTR_TF: the occurrence counter is triggered after the fault confirmation was successful DemGeneral/'''DemOperationCycleProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[operation cycle]]s are triggered by DEM_CYCLE_STATE_START or collecting an external counter value, which results in respective state changes. * DEM_PROCESS_OPCYC_COUNTER: operation cycle processing is based on [[API]] [[Dem_SetOperationCycleCntValue]] * DEM_PROCESS_OPCYC_STATE: operation cycle processing is based on API [[Dem_SetOperationCycleState]] DemGeneral/'''DemOperationCycleStatusStorage''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the operation cycle state is available over the [[power cycle]] (stored non-volatile) or not. * TRUE: the operation cycle state is stored [[non-volatile]] * FALSE: the operation cycle state is only stored [[volatile]] DemGeneral/'''DemPTOSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether [[PTO]] support (and therefore [[PID]] $1E support) is enabled or not. DemGeneral/'''DemStatusBitHandlingTestFailedSinceLastClear''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[aging]] and displacement mechanism shall be applied to the "[[TestFailedSinceLastClear]]" status bits. * DEM_STATUS_BIT_AGING_AND_DISPLACEMENT: the "TestFailedSinceLastClear" status bits are reset to 0, if aging or displacement applies (like done for the "[[ConfirmedDTC]]" status bits) * DEM_STATUS_BIT_NORMAL: aging and displacement has no impact on the "TestFailedSinceLastClear" status bits DemGeneral/'''DemStatusBitStorageTestFailed''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the permanent storage of the "[[TestFailed]]" status bits. * TRUE: storage activated * FALSE: storage deactivated DemGeneral/'''DemStorageConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for storage conditions is enabled or not. * TRUE: support for storage conditions is enabled * FALSE: support for storage conditions is disabled DemGeneral/'''DemTaskTime''' {1, [[EcucFloatParamDef|Float]]; [[Pre-compile time|Pre]]; 0..0.1} Allow to configure the time for the periodic [[cyclic task]]. Please note: This configuration value shall be equal to the value in the [[Basic Software Scheduler]] configuration of the [[RTE]] module. The AUTOSAR configuration standard is to use [[SI unit]]s, so this parameter is defined as float value in seconds. Dem configuration tools must convert this float value to the appropriate value format for the use in the software implementation of Dem. Exactly one DemTaskTime must be specified per configuration. * min: A negative value is not allowed. * max: After event status was reported, processing shall be completed within 100ms in order to have the fault entry status information updated as soon as possible (e.g. for PID $01). DemGeneral/'''DemTriggerDcmReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Diagnostic Communication Manager]] for [[ROE processing]]. * TRUE: Dcm ROE notification activated * FALSE: Dcm ROE notification deactivated DemGeneral/'''DemTriggerDltReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Diagnostic Log and Trace]]. * TRUE: Dlt notification activated * FALSE: Dlt notification deactivated DemGeneral/'''DemTriggerFiMReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Funciton Inhibition Manager]]. * TRUE: FiM notification activated * FALSE: FiM notification deactivated DemGeneral/'''DemTriggerMonitorInitBeforeClearOk''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the monitor re-initialization has to be triggered before or after the Dem module returns DEM_CLEAR_OK. * TRUE: trigger re-initialization before DEM_CLEAR_OK * FALSE: trigger re-initialization after DEM_CLEAR_OK DemGeneral/'''DemTypeOfDTCSupported''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the format returned by [[Dem_GetTranslationType]] and does not relate to/influence the supported Dem functionality. * DEM_DTC_TRANSLATION_ISO11992_4: [[ISO11992-4]] DTC format * DEM_DTC_TRANSLATION_ISO14229_1: [[ISO14229-1]] DTC format (3 byte format) * DEM_DTC_TRANSLATION_ISO15031_6: [[ISO15031-6]] DTC format (2 byte format) * DEM_DTC_TRANSLATION_SAEJ1939_73: [[SAEJ1939-73]] DTC format DemGeneral/'''DemTypeOfFreezeFrameRecordNumeration''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of assigning [[freeze frame]] record numbers for event-specific freeze frame records. * DEM_FF_RECNUM_CALCULATED: freeze frame records will be numbered consecutive starting by 1 in their chronological order * DEM_FF_RECNUM_CONFIGURED: freeze frame records will be numbered based on the given configuration in their chronological order DemGeneral/'''DemVersionInfoApi''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the version information [[API]]. * TRUE: version information activated * FALSE: version information deactivated DemGeneral/'''DemMILIndicatorRef''' {0..1, [[DemIndicator|Reference]]; [[Pre-compile time|Pre]]} This parameter defines the indicator representing the [[MIL]]. This parameter is mandatory for [[ECU]]s supporting [[OBD]] (refer to [[DemOBDSupport]]). 0c21176e750c03dad535c2be38ea8f822a8ca45c 0 565 1367 867 2014-10-15T10:23:28Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Diagnostic Log and Trace (DLT) is a [[Basic Software Module]] of the [[Diagnostic Services]]. It provides a generic Logging and Tracing functionality. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 27aae7bfda45a733c349d7cb8a822cab4ccd3e2d 0 602 1368 874 2014-10-15T10:23:31Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A ´Diagnostic Event´ (identified by an [[EventId]] as a symbolic [[EventName]]) defines the atomic unit that can be handled by the [[Dem]] module. The status of a ´Diagnostic Event´ represents the result of a [[diagnostic monitor]]. The Dem receives the result of a monitor from [[SW-C]] via the [[RTE]] or other [[BSW module]]s. 85d33f3f7c62f7b3011891def806b907340f3f1e 0 603 1369 902 2014-10-15T10:23:42Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A diagnostic monitor is a routine entity determining the proper functionality of a component by identifying a specific fault type (e.g. short to ground, open load, etc.) for a [[monitoring path]]. Alternatively the term “diagnostic function” can be used. 9e82ced43f03954f790f9303ef577e3e43ad0f42 0 155 1370 824 2014-10-15T10:24:18Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A functional and complete description of a specific [[communication stack]] in terms of data structures, [[service|services]], behavioral state-machines, error handling. [[E2E]] Profiles are defined in AUTOSAR [[E2E Library]]. An E2E Profile is configurable by runtime parameters. A specific set of runtime parameters is called E2E profile variant. In order to reach [[interoperability]], the application developers should use the E2E profile variants defined in the E2E [[library]]. 8ff2276fbf91f970a2c9323325fe6834b20c7211 0 393 1371 484 2014-10-15T10:24:21Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The ECU-Abstraction [[Software Component]] provides access to the [[ECU]]’s specific [[IO]] capabilities. These services are typically provided through client-server [[PPort]]s and are used by the [[sensor-actuator software component]]s. The ECU-abstraction may directly interact with certain other [[basic-software module]]s. 1fa808def8b810e4c23aab193d62f625bfd863a1 0 157 1372 924 2014-10-15T10:24:25Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Activity]] of integrating and configuring one [[ECU]]’s software. Further Explanations: ECU Configuration denotes the activity when one ECU's software is set up for a specific usage inside the ECU. In AUTOSAR the ECU Configuration activity is divided into [[Pre-compile time]], [[Link time]] and [[Post-build time]] configuration. It is the entire configuration of the [[Basic Software]] and the [[RTE]] of a single [[ECU]]. de56bea8c44933f05f8a1fee09a1940190bb61f6 0 158 1373 508 2014-10-15T10:24:29Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Output of the [[ECU Configuration]] activity containing the values of configuration parameters and references. [[ECU]] Configuration Description holds the configuration parameter values and references to other [[module]]'s configurations which have been defined in the ECU Configuration [[activity]]. ECU Configuration Description may contain the whole ECU Configuration information or only the parts relevant for a specific configuration step (e.g. [[Pre-compile time]]). 002fb073ed2be640d6a89af6c3843b8628956e75 0 411 1374 526 2014-10-15T10:24:32Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[System Configuration Description]] is used as a basis to generate ECU Extracts ([[arxml]] file) which directly contain all relevant information to be integrated on an [[ECU]]. The ECU Extract is the basis for setting up the ECU configuration and further development on ECU level. af0dc4cc00f92939346aff7c43c0a9d80832fb30 0 562 1375 869 2014-10-15T10:24:36Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The ECU State [[Manager]] (EcuM) is a [[Basic Software Module]] of the [[System Services]]. It is responsible for the basic initialization and de-initialization of basic software components. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === ca34cbb28fdf76d2dd8e7f6fb0be191d7097dd33 0 353 1376 411 2014-10-15T10:25:40Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A vendor ID is a unique identification of the [[vendor]] of a [[software component]]. All [[Basic Software Module]]s conformant to the [[AUTOSAR]] standard shall provide a readable vendor ID. AUTOSAR Vendor IDs are used to determine vendors of basic software modules before and during runtime. The mechanism is used to improve [[bug]] handling. AUTOSAR currently only provides Vendor IDs to members of the AUTOSAR partnership. 3568eb6c2ec782f90df1a393819e8340b0841889 0 258 1377 300 2014-10-17T21:33:17Z Oliver 1 wikitext text/x-wiki An [[M1-level|M1]] - Model, it is an instance of the [[Meta Model]]. e300a7031804b4acb4825a3414ff3da99f525354 0 882 1378 2014-10-17T21:34:12Z Oliver 1 Created page with "Metamodel elements of [[M2-level]] may be used in an application model (M1-level) to describe the content of a real vehicle." wikitext text/x-wiki Metamodel elements of [[M2-level]] may be used in an application model (M1-level) to describe the content of a real vehicle. c1681810f31178efd394bbea4bcce2093bfd41a4 0 883 1379 2014-10-17T21:35:45Z Oliver 1 Created page with "[[AUTOSAR]] uses the [[UML]] metamodel (M2-level) to describe the classes and objects that may be used in an AUTOSAR-compliant system. These [[metamodel element]]s may be used..." wikitext text/x-wiki [[AUTOSAR]] uses the [[UML]] metamodel (M2-level) to describe the classes and objects that may be used in an AUTOSAR-compliant system. These [[metamodel element]]s may be used in an application model ([[M1-level]]) to describe the content of a real vehicle. [[ECU Configuration]] is a part of the AUTOSAR standard so the elements of [[ECU Configuration Description]] must be described in the UML metamodel at M2-level. The (M2) metamodel has therefore been populated with UML descriptions from which [[ECU Configuration Parameter]] models may be built. 41b4fb354eb9e7acb283c60bdd3b7990ad76cad4 1424 1379 2014-10-22T06:56:59Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[AUTOSAR]] uses the [[UML]] metamodel (M2-level) to describe the classes and objects that may be used in an AUTOSAR-compliant system. These [[metamodel element]]s may be used in an application model ([[M1-level]]) to describe the content of a real vehicle. [[ECU Configuration]] is a part of the AUTOSAR standard so the elements of [[ECU Configuration Description]] must be described in the UML metamodel at M2-level. The (M2) metamodel has therefore been populated with UML descriptions from which [[ECU Configuration Parameter]] models may be built. 053c8bc8bce63a294329999c4222a321d7b77267 0 545 1380 830 2014-10-20T18:06:20Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The IO HW Abstraction (IoHwAb) is a [[Basic Software Module]] of the [[I/O HW Abstraction]] layer. It abstracts from the location of peripheral I/O devices (on-chip or on-board) and the [[ECU]] hardware layout (e.g. [[uC]] pin connections and signal level inversions). The I/O Hardware Abstraction does not abstract from the sensors/actuators! The different I/O devices might be accessed via [[I/O Drivers]]. === [[AUTOSAR Interface]] === Project (resp. hardware) specific. === [[Standardized AUTOSAR Interface]] === none === [[Standardized Interface]] === none fe607c3cca45fb55c3713ca0f5d4768dbf37f5f7 0 884 1381 2014-10-20T18:06:31Z Oliver 1 Redirected page to [[IO HW Abstraction]] wikitext text/x-wiki #REDIRECT [[IO HW Abstraction]] 1a27cd78d10a3149dd8182cb315bb3e90f9f75cd 0 885 1382 2014-10-22T06:38:35Z Oliver 1 Redirected page to [[Failure Memory]] wikitext text/x-wiki #REDIRECT [[Failure Memory]] 072923a36fa20c13a9c3cfc6153d38e03877e414 0 852 1383 1307 2014-10-22T06:39:47Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[AUTOSAR]] Tool Platform User Group see [https://www.artop.org/organization] f3a6d2fa03a97bb40d69f08c5ade01f41be48db1 0 508 1384 788 2014-10-22T06:40:37Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The CAN [[Driver]] (Can) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 842bb46c243e45def59879242c44fe6311cc7a3a 0 523 1385 694 2014-10-22T06:40:58Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The CAN Network Management (CanNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 752ad8dac5d22524782de5f597f972296d39e700 0 524 1386 812 2014-10-22T06:41:03Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The CAN State [[Manager]] (CanSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 57a8c826dbb51b589f8a4e852d725630fb6d6c44 0 515 1387 686 2014-10-22T06:41:08Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The CAN Tranceiver Driver (CanTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === daa7c7bf78dfeca6921b88868734d5e7172bec92 0 525 1388 696 2014-10-22T06:41:13Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The CAN Transport Layer (CanTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 6c26c948e9c68ad8aa32b688a33e05ae9b958cef 0 133 1389 619 2014-10-22T06:42:11Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A specific form of communication in a possibly distributed system in which software entities act as [[client]]s, [[server]]s or both, where 1...n clients are requesting [[service]]s via a specific protocol from typically one server. Client-server communication can be realized by [[synchronous communication]] or [[asynchronous communication]]. -Client takes initiative: requesting that the server performs a service, e.g. client triggers action within server (server does not start action on its own) -Client is after service request blocked / non-blocked -Client expects response from server: [[data flow]] (+ [[control flow]], if blocked) One example for 1 client to n server communication (currently not supported) is a functional request by diagnosis. This has to be treated as a specific exception. c53a3ad39233dc9f5e69400ae9421afaf740b699 0 385 1390 472 2014-10-22T06:42:29Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A component-type is either a [[Composition]] or [[Atomic]]. f576dafd9014d8ca7c50981c0ae7ca062b9d0c24 0 624 1391 957 2014-10-22T06:43:24Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A computation method that can be used to transform [[fixed-point]] representations of variables in the [[ECU]] memory into corresponding [[physical value]]s and vice versa. Compu methods define the relationship between internal values of the [[Software Component]] on the target ECU and converted values (real-world, physical). Compu methods are optional (not mandatory) for [[Port Interface]]s. 839d74a94649fe6f294effbcf34c088d220f01cc 0 412 1392 527 2014-10-22T06:43:45Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] In a design step called “Configure System”, the [[SWC|components]] are mapped on specific system resources ([[ECU]]s). Thereby, the [[virtual connection]]s between the components are mapped onto local connections (within a single ECU) or on network-technology specific communication mechanisms (such as [[CAN]] or [[FlexRay]] frames). The [[VFB]] can be used for plausibility checks concerning the communication of software components. 18474b37ce62394c8877b8b513c08ee9a9db70d3 0 578 1393 837 2014-10-22T06:43:58Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[Basic Software]] supports the following configuration classes: == Pre-compile time == * [[Preprocessor]] instructions * Code generation (selection or synthetization) == Link time == * Constant data outside the module; the data can be configured after the module has been compiled == Post-build time == * Loadable constant data outside the module. Very similar to Link Time, but the data is located in a specific memory segment that allows reloading (e.g. re-flashing in [[ECU]] production line) * Single or multiple configuration sets can be provided. In case that multiple configuration sets are provided, the actually used configuration set is to be specified at runtime. f6d23076e2bc2ea8b70ccf444593e3e95ddb4b41 0 670 1394 1040 2014-10-22T06:44:44Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A Data Type is an element that classifies a particular type of information, a set of data having predefined characteristics. The characteristics of a Data Type define the values that a variable can contain. The properties of a Data Type define the values that a variable can contain. = Application Data Type = Application Data Types support the application view of developing [[ECU]] software (resp. the view of [[Software Component]]s). = Implementation Data Type = Implementation Data Types let the [[integrator]] specify the implementation details such as [[Software Base Types]] or [[endianness]]. = Primitive Data Type = [[Integer]], [[Enumeration]], [[Boolean]], etc. ae2a8e5fa723bfde28afaa5e6f1a555183af7b94 0 150 1395 166 2014-10-22T06:45:05Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Adaptation of [[SW]] by setup of certain characteristic [[data]] according to external requirements. Data Variant Coding might influences [[RTE]] (RunTimeEnvironment) and [[BSWM|BSW modules]] not only the [[application software]] modules. (Multiple configuration parameter sets are needed.) Variant Coding is always done at [[post-build]] time. Variant Coding also includes [[vehicle-specific]] (not [[user-specific]]) SW adaptation due to end-customer wishes (e.g. deactivation of speed dependent automatic locking). Used techniques to select variants include end-of-line programming and garage programming. The major difference with [[calibration]] is that this later doesn’t aim to adapt the SW functionality itself but only aims to adjust the characteristic data of the SW to the [[HW]]/SW environment. Characteristic data in the source code of a software function have a significant impact on the functionality of the software. 9af1ffe7f94537cafc7ef2519c53032c5c108990 0 550 1396 721 2014-10-22T06:45:10Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The EEPROM Abstraction (Ea) is a [[Basic Software Module]] of the [[Memory HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === ef785009cb7a9803731c02e595e83d9272aacd42 0 546 1397 799 2014-10-22T06:45:15Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The EEPROM [[Driver]] (Eep) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === aa46aeb52b088791802100a1048b323e87d5c428 0 509 1398 789 2014-10-22T06:45:20Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Ethernet [[Driver]] (Eth) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === d8e2b022447daaf28d9f8ae44fcfaf7dfbdbd1a4 0 516 1399 687 2014-10-22T06:45:25Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Ethernet Interface (EthIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 1bc856c25a5ae692d2dbe79b9ff8131122a7cb7b 0 526 1400 813 2014-10-22T06:45:30Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Ethernet State [[Manager]] (EthSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 8473453cd78e6e0eabd51c15c704a9905f67c002 0 517 1401 688 2014-10-22T06:45:36Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Ethernet Transceiver Driver (EthTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 50cb63b34225fb1d3eb20483bd835051cf76374b 0 166 1402 953 2014-10-22T06:48:59Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] State change of a hardware and/or software entity. See also [[OS event]] and [[RTE Event]]. c7027a046f262934abc43ae0d373aaf182db0da8 0 661 1403 1011 2014-10-22T06:49:16Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Event retention is defined as the ability of the [[Dem]] module to record and handle [[event]]s ([[DTC]]s), DTC status information and event related data (e.g. [[freeze frame]]s, extended data). 2b4bfc6eab78f8c56017cda20d27769c41c95f83 0 527 1404 698 2014-10-22T06:49:44Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The FlexRay AUTOSAR Transport Layer (FrArTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === de7ea85991ec93dee43cc205d7e772c7009504c4 0 510 1405 790 2014-10-22T06:49:50Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The FlexRay [[Driver]] (Fr) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 657b439d51d17a2d1643843f97807f04aa18607c 0 518 1406 689 2014-10-22T06:49:55Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The FlexRay Interface (FrIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 76d66e0e7aa1814c49f4d78f4c18b53b32f0eb05 0 529 1407 700 2014-10-22T06:50:02Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The FlexRay Network Management (FrNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 90327b65fa0ff592c29c6ec31879f3dd7004066c 0 555 1408 801 2014-10-22T06:50:51Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The GPT [[Driver]] (Gpt) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 2f841fcff8a5d70010ccc98393391fd74825ec6c 0 452 1409 1021 2014-10-22T06:50:56Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Function Inhibition [[Manager]] (FIM) is a [[Basic Software Module]] of the [[Diagnostic Services]]. The FiM stands for the evaluation and assignment of events to the required actions for [[Software Component]]s (e.g. inhibition of specific “Monitors”). The Function Inhibition Manager is responsible for providing a control mechanism for software components and the functionality therein. In this context, a functionality can be built up of the contents of one, several or parts of [[runnable entity|runnable entities]] with the same set of permission / [[inhibit condition]]s. By means of the FIM, the inhibiting of these functionalities can be configured and even modified by [[calibration]]. Therefore, the adaptation of a functionality into a new system context with modified physical boundary conditions and influences is significantly enhanced. A functionality in the sense of the FIM and a runnable entity are different and independent types of classifications. Runnable entities are mainly featured by their scheduling requirements. In contrast to that, functionalities are classified by their inhibit conditions. The services of the FIM focus on applications in the SW-Cs, however, they are not limited to them. Functionalities of the [[BSW]] can also use the FIM services. Note, there is no functional relationship between [[RTE]] and FIM. The RTE only provides communication in the sense that it connects the required ports of the SW components with the provided [[port]](s) of the FIM. But the RTE does not implement any functionality of the FIM. In contrast to that, the FIM deals with inhibit conditions and provides supporting mechanisms for controlling functionalities within [[runnables]] via respective identifiers ([[FID]]). Therefore, the FIM and RTE concepts do not interfere with each other. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Fim_GetFunctionPermission === [[Standardized Interface]] === Fim_DemTriggerOnEventStatus 064fd9648a03413667657afba9fd871e2f89e513 0 519 1410 690 2014-10-22T06:50:59Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The FlexRay Tranceiver Driver (FrTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 6c666a2bff099f785c620b24d1089e5148a81e80 0 530 1411 814 2014-10-22T06:51:03Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The FlexRay State [[Manager]] (FrSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === ecbd863662194ff5fde85213d142b3676b8cb679 0 542 1412 796 2014-10-22T06:52:02Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The ICU [[Driver]] (Icu) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 50b659c1b00f6572a4ebc2542d7a6a8af6f7441f 0 531 1413 702 2014-10-22T06:52:08Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The IPDU Multiplexer (IpduM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === ed52bead3c1c6ebcf6b2a655b293c12eb46bb3f6 0 630 1414 1000 2014-10-22T06:52:12Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Modeling element for specifying communication between the runnable entities in one [[Atomic Software Component]]. An interrunnable variable is a [[variable data prototype]] that requires an [[application data type]] which can have a [[compu method]] and a [[data constraint]] element like the variable data prototype of a [[Sender-Receiver Interface]]. Interrunnable variables can be: * [[Implicit]] which means the runnable entity works on a local copy of an interrunnable variable. A copy of read interrunnable variables is created on entry of the runnable. Changes are written back when the runnable entity completes. This avoids concurrent access to interrunnable variables during runnable entity execution. * [[Explicit]] which means the runnable entity can directly access an interrunnable variable. Changes are immediately visible to other runnable entities with explicit access to the interrunnable variable. 3a23221a15d8db96951f450a8dd714ba15e79f7b 0 633 1415 941 2014-10-22T06:52:16Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The IsService flag on an [[interface]] indicate whether the [[Client-Server Interface]] is provided by a [[Basic Software Module]]. f658d1edb4bbdd4923d3381d6230514f320722c6 0 511 1416 791 2014-10-22T06:52:20Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The LIN [[Driver]] (Lin) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === e8f6a5346b3ce710801ac505193862c21db7a20b 0 520 1417 691 2014-10-22T06:52:25Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The LIN Interface (LinIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === c65b97d1d4737f5879b1f39fd261fed355ea774c 0 532 1418 703 2014-10-22T06:52:28Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The LIN Network Management (LinNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 1365bbeef0d3576f160ec073890de89027e05080 0 533 1419 815 2014-10-22T06:52:32Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The LIN State [[Manager]] (LinSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 4b25e4eacda1604802c346184811cf676324fd38 0 521 1420 692 2014-10-22T06:52:36Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The LIN Transceiver Driver (LinTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 5a190f821506bad4b46a5e6b72f63336518bd7ee 0 1 1421 1 2014-10-22T06:56:36Z Oliver 1 wikitext text/x-wiki Welcome! This automotive wiki is provided to you by [http://www.scheid-automotive.com SCHEID automotive GmbH]. For browsing AUTOSAR topics you may want to start with [[Basic Software Module]]s. 9268b03c0ad2e1e5baba8102908ffd0605561752 0 251 1422 291 2014-10-22T06:56:51Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[MCAL]] signal is the software representation of the [[conditioned signal]]. It is provided by the microcontroller abstraction layer (MCAL) and is further processed by the [[ECU abstraction]]. The processing unit is accessing the Conditioned Signal through some peripheral device that typically digitizes the Conditioned Signal into a software representation. The transformation from the Conditioned Signal to the MCAL Signal has to take the digitalization error into account in order to provide information about the quality loss between the [[Technical Signal]] and the MCAL Signal. 84642f0d6330a99a314035630116920fdb94ba56 0 882 1423 1378 2014-10-22T06:56:55Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Metamodel elements of [[M2-level]] may be used in an application model (M1-level) to describe the content of a real vehicle. 3e18cd055447162e02f11b29f177e972957e9c4e 0 556 1425 802 2014-10-22T06:57:03Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The MCU [[Driver]] (Mcu) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 5f49af43ec999ad1477502e2ee3a154d899ae035 0 660 1426 1004 2014-10-22T06:57:08Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Application data type]]s have to be mapped to [[Implementation data type]]s before generating the [[RTE]]. For this purpose a data type mapping set has to be defined per [[SW-C]] [[internal behavior]]. Also constants that have application data types might need a [[constant specification]] mapping set defined. d3477ce8a0acc12bfc2d35486bc20420230099b1 0 635 1427 944 2014-10-22T06:57:11Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] MemMap configuration is the configuration of the [[MemMap module]] for one [[ECU]]. The MemMap configuration is part of the [[ECU configuration]]. c450ec8dab62dab96ea20e6555b766ec07150881 0 552 1428 723 2014-10-22T06:57:16Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Memory Abstraction Interface (MemIf) is a [[Basic Software Module]] of the [[Memory Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f0fc85d9276bbec515eba07489102df5353bbb9a 0 636 1429 946 2014-10-22T06:57:56Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The mode declaration group is an element that contains the possible [[operating state]]s of an [[ECU]], single functional unit, etc. 380aac494139e9f55c7837f8bce8980f4aae3a62 0 851 1430 1306 2014-10-22T06:58:01Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] When a [[mode]] disabling is active, [[RTE]] and [[Basic Software Scheduler]] disables the start of mode disabling dependent ExecutableEntitys. The mode disabling is active during the mode that is referenced in the mode disabling dependency and during the transitions that enter and leave this mode. 47bd4d9c3824cfff3ba7499df1d9e47bca32668f 0 850 1431 1305 2014-10-22T06:58:05Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A [[mode disabling]] dependent [[Runnable Entity]] or a [[Basic Software Schedulable Entity]] is triggered by an [[RTE Event]] respectively a [[BSW Event]] with a ModeDisablingDependency. [[RTE]] and [[Basic Software Scheduler]] prevent the start of those Runnable Entity or Basic Software Schedulable Entity by the RTEEvent / BswEvent, when the corresponding mode disabling is active. a032a47a79a925aa1c5b4bb53d747fc83d036301 0 847 1432 1300 2014-10-22T06:58:09Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The instances of [[mode]] machines or ModeDeclaration-Groups are defined by the ModeDeclarationGroup-Prototypes of the [[mode manager]]s. Since a [[mode switch]] is not executed instantaneously, the [[RTE]] or [[Basic Software Scheduler]] has to maintain it’s own states. For each mode manager’s ModeDeclarationGroupPrototype, RTE or Basic Software Scheduler has one [[state machine]]. This state machine is called mode machine instance. For all mode users of the same mode manager’s ModeDeclarationGroupPrototype, RTE and Basic Software Scheduler uses the same mode machine instance. 24760ea1b7ddfe96b35c537480fc2e41a4ec1cbe 0 844 1433 1296 2014-10-22T06:58:12Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Entering and leaving [[mode]]s is initiated by a mode manager. A mode manager is defined by having a provide [[mode switch port]] or a providedModeGroup ModeDeclarationGroupPrototype. A mode manager might be either an application mode manager or a [[Basic Software Module]] that provides a service including mode switches, like the [[ECU State Manager]]. 51dab13e37c0a987ae0b56221897d50df746be94 0 846 1434 1299 2014-10-22T06:58:16Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The communication of a [[mode switch]] from the [[mode manager]] to the mode user using either the ModeSwitchInterface or providedModeGroup and requiredModeGroup ModeDeclarationGroupPrototypes [[Link title]]is called mode switch notification. e4546a6ae06864bc7f8bd139e4211027f70cb2b5 0 842 1435 1298 2014-10-22T06:58:20Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[port]] for receiving (or sending) a [[mode switch notification]]. For this purpose, a [[mode switch]] port is typed by a [[Mode Switch Interface]]. 68cfe10de33cd820db63953fceae40473913e0db 0 843 1436 1303 2014-10-22T06:58:25Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] An [[AUTOSAR]] [[SW-C]] or AUTOSAR [[Basic Software Module]] that depends on modes by [[ModeDisablingDependency]], SwcModeSwitchEvent, BswModeSwitchEvent, or simply by reading the current state of a [[mode]] is called a mode user. A mode user is defined by having a require [[mode switch port]] or a requiredModeGroup ModeDeclarationGroupPrototype. dfdd769415bad134057b09ba49228ec70858becd 0 383 1437 945 2014-10-22T06:58:40Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The mode switch [[interface]] is used to notify a [[Software Component]] of a [[mode]]. The [[Mode Manager]] provides modes that can be used by [[mode user]]s to adjust the behavior according to modes or synchronize activities to mode switches. It is an interface that contains a [[mode declaration group]]. Via a mode switch interface a Software Component can get information on a mode switch. 71ad06fbd68544e8c82ebf3e646af0ffb2b2137c 0 2 1438 3 2014-10-22T06:59:33Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The “NVRAM Block” is the entire structure, which is needed to administrate and to store a block of [[NV data]]. 1dc5d50d84582b43ed2fcd67e06d09292631e747 0 637 1439 947 2014-10-22T06:59:57Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The NvM configuration is the configuration of the [[NVRAM Manager Module]] for one ECU. An NvM configuration is part of an [[ECU configuration]]. 40a0611eda027acec7477034ede5acdb4a970cd5 0 381 1440 459 2014-10-22T07:00:01Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Provide element level access (read only or read/write) to [[Non Volatile Data]] as opposed to [[NV block]] access. 2d7c07bd9f59cca565089c067fee464152b65d0f 0 534 1441 705 2014-10-22T07:00:06Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Network Management Interface (Nm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 56ad6ce2cd9b0daa6769fd5c27e4f77af9e94172 0 264 1442 1062 2014-10-22T07:00:09Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A Network Interface is the sum of all [[interface]]s offered by the [[Basic Software]] towards its connected [[network]]. The interface that the Basic Software shares via the [[communication line]]s with other systems that behave like AUTOSAR ECUs in order to - allow distributed [[SW-C]]s to exchange [[inter-ECU signal]]s and to - operate the communication lines (the network) is called Network Interface. A Network Interface (NWI) denotes the interface between the Basic Software and the [[physical network]] ([[OSI]] Layer 0) to which the ECU executing the Basic Software is connected to (e.g. [[CAN]], [[LIN]], [[FlexRay]]). The NWI therefore transports [[network data packet]]s between the Basic Software and the physical network. The interfaces included within the term NWI are: - [[Logical interface]]s, including o Network Management o Data Management o Data transmission/reception The interfaces excluded from the term NWI are: - The physical network interface (CAN, FlexRay etc.). Note that, while attention must be given to the physical form of the network, since it is not formally specified by AUTOSAR, it cannot be considered a part of the conformance test of an AUTOSAR cluster. The NWI provided by a given ECU supports the transfer of data to and from the ECU, and management of the network. For the purposes of this definition, the Basic Software can be designed according to [[ICC1]], [[ICC2]] or [[ICC3]]. f36fb91f213c410a821d56527644d377f5287083 0 396 1443 488 2014-10-22T07:00:13Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The NV Block [[Software Component]] allows SW-Cs access to [[non volatile data]]. Specifically this block allows for the modeling of the NV data at the [[VFB]] level. It is the responsibility of the [[NV Block]] to map individual [[NV data element]]s to NV Blocks and to interact with the [[NV Manager]] in the [[BSW]]. The behavior of this component is to be generated based on the [[port service]]s in the [[RTE]]. 7df51bc1fe6db7ac353fd7aee2ac948084737eea 0 9 1444 11 2014-10-22T07:00:16Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Additional information included in the [[NV Block]] if the mechanism “[[Static Block ID]]” is enabled. 1c6505564dd15c08ef127cbbb2176ee821935a4a 0 8 1445 10 2014-10-22T07:00:20Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The „NV Block“ is a [[Basic Storage Object]]. It represents the part of a [[NVRAM Block]] which resides in the [[NV memory]]. The „NV Block“ is a mandatory part of a [[NVRAM Block]]. 1eeb6724052f9e335c7988ad50a858ff4d02ca75 0 553 1446 817 2014-10-22T07:00:24Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The NVRAM [[Manager]] (NvM) is a [[Basic Software Module]] of the [[Memory Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === a36986c361698f3e306fcb461bd56e645ad293cb 0 543 1447 797 2014-10-22T07:02:07Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The PWM [[Driver]] (Pwm) is a [[Basic Software Module]] of the [[I/O Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 6e6c09796fb0b117002c876bf33bbf32b484dcdd 0 388 1448 478 2014-10-22T07:02:10Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A Parameter Software Component provides parameter values. These can be fixed data, const or variable. This [[Software Component]] allows for data access to either fixed data or [[calibration data]]. 5025644e6cc922e82e14f56507c575b262cb63b8 0 641 1449 964 2014-10-22T07:02:14Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A parameter data prototype specifies an [[ECU]] variable that can be [[calibrate]]d. They can have one of the following roles: * [[Per instance memory]] (PIM) in a [[Software Component]] [[internal behavior]] * [[Shared parameter]] in a Software Component internal behavior * [[Constant memory]] in a Software Component internal behavior * Parameter value in a [[parameter interface]] a76d5fbd279de8f9737dcd21a7e8d592dcc3f17c 0 643 1450 1034 2014-10-22T07:02:17Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Per instance memory is instantiated for each instance (prototype) of an atomic [[software component]] of the [[RTE]]. A [[Data Type]] instance can be accessed only by the corresponding atomic software component instance (prototype). 784bebcbb23413980139ef80512da4eedd56a7cd 0 286 1451 463 2014-10-22T07:02:21Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Specific [[Port]] providing [[data]] or providing a [[service]] of a [[server]] as defined in the [[Port Interface]]. The Provide Port is sometimes abbreviated as PPort or P-Port. 2670858891b57549f39004cfc75a3d04a2909b04 1458 1451 2014-10-22T07:05:10Z Oliver 1 Redirected page to [[Port#Provide Port]] wikitext text/x-wiki #REDIRECT [[Port#Provide Port]] f05748abf975ccfc134da01abe9abdfb75063b4d 0 302 1452 994 2014-10-22T07:02:24Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] An RTE [[Event]] encompasses all possible situations that can trigger execution of a [[runnable entity]] by the [[RTE]]. Thus they can address timing, data sending and receiving, invoking [[operation]]s, call [[server]] returning, [[mode switch]]ing, or external [[event]]s. RTE Events can either activate a runnable entity or wakeup a runnable entity at its [[wait point]]s. Note ‘event’ in this context is not necessarily synonymous with ‘RTEEvent’ as defined in the [[VFB]] specification. In particular, RTE Events that result from communication are handled by communication-triggered runnable entities. An RTE event is part of an SW-C [[internal behavior]]. It defines situations and conditions for starting or continuing the execution of a specific [[runnable entity]]. = Timing event = Triggers a [[runnable entity]] periodically = Data received event = Triggers a runnable entity as soon as a [[variable data prototype]] is received at the [[port]]. 6666399460bb429ab6f0731efb285e9f242a2efc 0 645 1453 970 2014-10-22T07:02:34Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The RTE configuration is the configuration of the [[RTE]] for one [[ECU]]. An RTE configuration is part of an [[ECU configuration]]. fe0efe43f9d6bd2c5469f576110eb0cb7307985a 0 293 1454 464 2014-10-22T07:02:38Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Specific [[Port]] requiring [[data]] or requiring a [[service]] of a [[server]] as defined in the [[Port Interface]]. The Require Port is sometimes abbreviated as RPort or R-Port. a054bbcd392cfb39255c0d16a55930dfd1a44730 1461 1454 2014-10-22T07:06:23Z Oliver 1 Redirected page to [[Port#Require Port]] wikitext text/x-wiki #REDIRECT [[Port#Require Port]] c2e8b8af528861a4d0cf01cbe24afbb5602b81de 0 414 1456 783 2014-10-22T07:02:44Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Runtime Environment implements the [[VFB]] functionality on a specific [[ECU]] to make [[Software Component]]s independent from the mapping to a specific [[ECU]]. The RTE is a layer providing communication services to the application software (Software Components and/or [[Sensor/Actuator SW-Component]]s). The SW-Cs communicate with other components ([[inter ECU]] and/or [[intra ECU]]) and/or [[service]]s via the RTE. 2469c46262201bf63ee97b3f2542c1310af18422 0 275 1457 967 2014-10-22T07:05:00Z Oliver 1 wikitext text/x-wiki A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[Provide Port]] (p-port, PPort) or a [[Require Port]] (r-port, RPort). A port of a SW-C is associated with a [[port-interface]]. The occurrence of an unconnected port is not per se a design mistake. It can be valid when an application provider for the [[data element]] is absent and the default init value is good enough to operate with or it could be that an end point was removed from the [[system]] because it is subjected to variability (See [[Variant Handling]]). Ports are the interconnection points between [[software component]]s. Ports of different SWC can be connected to indicate a data flow between them. The details, i.e. the kind of information that is actually transported between the ports, are defined by [[port-interface]]s. A port is a part of a software component that is an interaction point between that component and other software components. The interaction between ports is modeled via [[interface]]s. = Port Types = == Provide Port == Specific Port providing [[data]] or providing a [[service]] of a [[server]] as defined in the [[Port Interface]]. The Provide Port is sometimes abbreviated as PPort or P-Port. = Unconnected Ports = == Unconnected Sender Ports == Data of the sender will not appear on VFB. Generated RTE might simply call empty function or even optimize function call to zero code. == Unconnected Synchronous Receiver Ports == The RPort will always read the initial value specified for this RPort. == Unconnected Asynchronous Receiver Ports == The RPort will receive a time-out like the Sender is not providing data. == Unconnected Server Ports == The operations (functions) of the PPort interface will never be called. Generated RTE (or finally the compiler) might even optimize operation to zero code. == Unconnected Client Ports == According to AUTOSAR specification the [[operation]]s (functions) on the RPort will TIME_OUT. But more likely the [[RTE-Generator]] will generate a return code RTE_E_UNCONNECTED for any unconnected [[client]] interface operation. == Initial (default) values of a port == TODO 03e9a2987a76ac159d411bddefe4f6269ff83ac6 1462 1457 2014-10-22T07:06:44Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A port belongs to exactly one [[Software Component]] (SW-C) and is the interaction point between a SW-C and other SW-Cs. The interaction between specific ports of specific components is modeled using [[connector]]s. A port can either be a [[Provide Port]] (p-port, PPort) or a [[Require Port]] (r-port, RPort). A port of a SW-C is associated with a [[port-interface]]. The occurrence of an unconnected port is not per se a design mistake. It can be valid when an application provider for the [[data element]] is absent and the default init value is good enough to operate with or it could be that an end point was removed from the [[system]] because it is subjected to variability (See [[Variant Handling]]). Ports are the interconnection points between [[software component]]s. Ports of different SWC can be connected to indicate a data flow between them. The details, i.e. the kind of information that is actually transported between the ports, are defined by [[port-interface]]s. A port is a part of a software component that is an interaction point between that component and other software components. The interaction between ports is modeled via [[interface]]s. = Port Types = == Provide Port == Specific Port providing [[data]] or providing a [[service]] of a [[server]] as defined in the [[Port Interface]]. The Provide Port is sometimes abbreviated as PPort or P-Port. == Require Port == Specific [[Port]] requiring [[data]] or requiring a [[service]] of a [[server]] as defined in the [[Port Interface]]. The Require Port is sometimes abbreviated as RPort or R-Port. = Unconnected Ports = == Unconnected Sender Ports == Data of the sender will not appear on VFB. Generated RTE might simply call empty function or even optimize function call to zero code. == Unconnected Synchronous Receiver Ports == The RPort will always read the initial value specified for this RPort. == Unconnected Asynchronous Receiver Ports == The RPort will receive a time-out like the Sender is not providing data. == Unconnected Server Ports == The operations (functions) of the PPort interface will never be called. Generated RTE (or finally the compiler) might even optimize operation to zero code. == Unconnected Client Ports == According to AUTOSAR specification the [[operation]]s (functions) on the RPort will TIME_OUT. But more likely the [[RTE-Generator]] will generate a return code RTE_E_UNCONNECTED for any unconnected [[client]] interface operation. == Initial (default) values of a port == TODO 10e56db14fddc65cd736a9a5f3e912cb2c45d6f6 0 285 1459 333 2014-10-22T07:05:14Z Oliver 1 Redirected page to [[Port#Provide Port]] wikitext text/x-wiki #REDIRECT [[Port#Provide Port]] f05748abf975ccfc134da01abe9abdfb75063b4d 0 292 1460 340 2014-10-22T07:05:41Z Oliver 1 Redirected page to [[Port#Require Port]] wikitext text/x-wiki #REDIRECT [[Port#Require Port]] c2e8b8af528861a4d0cf01cbe24afbb5602b81de 0 312 1463 958 2014-10-22T07:08:13Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A communication pattern which offers asynchronous distribution of information where a [[sender]] communicates information to one or more [[receiver]]s, or a receiver receives information from one or several senders. The process of sending data does not block the sender and the sender usually gets no response from the receivers. Both for Sender-Receiver Communication and for [[Client-Server Communication]], one [[PPort]] can be connected to one or more [[RPort]]s (for multicast sending and multiple [[client]]s connected to a [[server]], respectively). Sender-Receiver communication can be queued or non-queued. = Queued S/R communication = If the sender-receiver communication is configured as queued, then the sent data is processed using a first-in-first-out ([[FIFO]]) queue with a specified length. = Non-queued S/R communication = If the sender-receiver communication is configured as non-queued, then the receiver always has access to the last sent data. 4d4dfa8c9904d066523ecb1aa804b442096a5f29 0 314 1464 974 2014-10-22T07:08:57Z Oliver 1 Redirected page to [[Sensor-Actuator Software Component]] wikitext text/x-wiki #REDIRECT [[Sensor-Actuator Software Component]] 21a1e7ee711227d0bfbfce5deaf404cce2145777 0 432 1465 554 2014-10-22T07:09:14Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Service needs are defined for a specific [[SW-C]] in the [[Software Component Description]] (SWCD). It defines the [[service interface]]s needed from the [[BSWM]]. a36b85ef864dc37009c23d40c8b8f437c47c906b 0 392 1466 975 2014-10-22T07:09:19Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A Service [[Software Component]] provides standardized [[service]]s through [[Standardized Interface]]s. To provide these services, this component may interact directly with certain other [[Basic Software Module]]s. An [[Atomic Software Component]] that provides service functionality via [[Interface#Standardized AUTOSAR interface|Standardized AUTOSAR interface]]s. It describes a specific Software Component which is part of the [[Basic Software]] and provides services of a specific [[ECU]]. Service component [[port]]s are connected to [[Application Software Component]]s via specific connectors. 01f2790e3f6127cf064b90ede7c62f8631c31fad 0 390 1467 481 2014-10-22T07:09:24Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Service Proxy [[Software Component]] is responsible for distribution of [[mode]]s throughout the [[system]]. Once deployed each [[ECU]] should have a copy of every instance of this [[software component type]]. However at the [[VFB]] level only one is necessary. 89a4a156b37f4e454a84cc0b6febac9855324c91 0 317 1468 557 2014-10-22T07:09:29Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A Service Port is a [[Port]] of an [[SW-C]], [[Complex Device Driver]] (CDD) and/or [[ECU Abstraction]] connected to an AUTOSAR [[Service]]. The [[interface]] of a Service Port has to be a Standardized [[AUTOSAR Interface]]. A Service Port does not need to be connected to another Port in the [[VFB View]]. de82ce8889d355c75bc4d440c8201612a91777f9 0 387 1469 831 2014-10-22T07:09:33Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Sensor-Actuator Software Component is an [[Atomic Software Component]] that handles the specifics of a [[sensor]] and/or [[actuator]]. It directly interacts with the [[ECU Abstraction Layer]]. [[Software Component]] dedicated to the control of a [[sensor]] or [[actuator]]. There will be several Sensor/ Actuator SW-Cs in each [[ECU]]. In general there will be one Sensor/Actuator SW-C for each sensor and one for each actuator (=> number of Sensor/Actuator SW-C = number of sensors + number of actuators). An [[Atomic Software Component]] that links from the software representation of a sensor/actuator to its [[hardware interface]] provided by the [[Basic Software]]. It has to be mapped to the ECU where the hardware is physically present. 373d848ee8a0f69ee23cc530847e2265fed73e67 0 320 1470 977 2014-10-22T07:10:00Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Functional Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the Software Component [[template]]. Software Components can be abbreviated as SW-Cs. A SW-C contains a [[Software Component Description]] (SWCD) and the [[Software Component Implementation|implementation]]. c041b4228a4c619892604fc36f436f7d63b147e2 0 419 1471 908 2014-10-22T07:10:04Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Software Component Description (SWCD) defines all properties of a [[Software Component]] like [[port]]s, [[interface]]s, [[behavior]]. This could be done by [[ARtext]] language description, or with some Software Tool. Software Component Description is an [[XML]] file that describes a software architecture according to AUTOSAR. d317934d4a0feedbd685763ae1a1b26163f0dd4a 0 647 1472 978 2014-10-22T07:10:07Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[Software Component]] implementation describes how a specific SW-C [[internal behavior]] is realized for a given platform ([[microcontroller]] type and [[compiler]]. A SW-C implementation mainly consists of a list of source files, object files, compiler attributes and dependencies between the make and [[build process]]. 3cefec8e35c8763e50141922a95a9dff6dc4c9dc 0 322 1473 1023 2014-10-22T07:10:11Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] A [[Software Component]] Interface (SW-CI) is the sum of all interfaces offered by the [[Basic Software]], towards the Software Component (SW-C). A SW-CI denotes the interface between an SW-C and the underlying [[Basic Software cluster]] including the [[RTE]]. The SW-CI therefore comprises all [[API]], [[function]]s and [[callback]]s that the SW-C requires from and provides to the Basic Software (generally by means of RTE mechanisms). It includes also the mechanisms allowing SW-Cs sharing the SW-CI to communicate with one another. For the purposes of this definition, the Basic Software clustered on an [[ECU]] can be designed according to [[ICC1]], [[ICC2]] and [[ICC3]]. 4b0b7a515dfccb2d5e4df252d755bc0ae6d85751 0 649 1474 989 2014-10-22T07:10:14Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[Software Component]] internal behavior represents the internal structure of an [[Atomic Software Component]]. It is characterized by its [[runnable entity|runnable entities]], [[RTE Event]]s, [[exclusive area]]s, [[Per instance memory]] and their interdependencies. The internal behavior is an element that represents the internal structure of an [[Atomic Software Component]]. It is characterized by [[elements]] such as * [[runnable entity|runnable entities]] * [[RTE Event]]s * [[data access definition]]s * [[interrunnable variable]]s and their interdependencies. A SW-C internal behavior is refined by a [[Software Component Implementation]]. b489312a69640a3a09174c59c9a4eb4290b36de4 0 323 1475 377 2014-10-22T07:10:18Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The arrangement of [[software element]]s in a SW [[system]]. A software element is a clearly definable software part. A software configuration is a selection version of [[software module]]s, [[software component]]s, [[parameter]]s and generator configurations. [[Calibration]] and [[Variant Coding]] can be regarded as subset of Software Configuration. d10fb7fe82af9709f3dca64f20fcbb82270b061d 0 435 1476 572 2014-10-22T07:10:42Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Standard Types are defined in file Std_Types.h == The following types are specified == === Std_ReturnType === This type can be used as standard [[API]] return type which is shared between the [[RTE]] and the [[BSW]] modules. typedef uint8 Std_ReturnType; Range: E_OK, E_NOT_OK, 0x02-0x3F (user specific errors), Bit 7 and Bit 8 are reserved. === Std_VersionInfoType === This type shall be used to request the version of a [[BSW]] module using the <Module name>_GetVersionInfo()function. <code> typedef struct { uint16 vendorID; uint16 moduleID; uint8 sw_major_version; uint8 sw_minor_version; uint8 sw_patch_version; } Std_VersionInfoType; </code> == The following symbols are specified == === E_OK, E_NOT_OK === <tt> E_OK := 0x00 E_NOT_OK := 0x01 </tt> === STD_HIGH, STD_LOW === <tt> STD_HIGH := 0x00 STD_LOW := 0x01 </tt> === STD_ACTIVE, STD_IDLE === <tt> STD_ACTIVE := 0x00 STD_IDLE := 0x01 </tt> === STD_ON, STD_OFF === <tt> STD_ON := 0x00 STD_OFF := 0x01 </tt> 018d994041377bc6037bfc2a9b4f96b306700e4a 0 564 1477 1280 2014-10-22T07:11:21Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Watchdog [[Manager]] (WdgM) is a [[Basic Software Module]] of the [[System Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === = Terms = * Alive Counter: An independent data resource in the Watchdog Manager in context of a Checkpoint to track and handle its amount of Alive Indications. * Alive Indication: An indication provided by a Checkpoint of a Supervised Entity to signal its aliveness to the Watchdog Manager. * Alive Supervision: Kind of supervision that checks if a Supervised Entity executed sufficiently often and not too often (including tolerances). * Checkpoint: A point in the control flow of a Supervised Entity where the activity is reported to the Watchdog Manager. * Deadline Supervision: Kind of supervision that checks if the execution time between two Checkpoints are lower then a given upper execution time limit. * Deadline Start Checkpoint: A Checkpoint for which Deadline Supervision is configured and which is a starting point for a particular Deadline Supervision. * Deadline End Checkpoint: A Checkpoint for which Deadline Supervision is configured and which is a ending point for a particular Deadline Supervision. It is possible that a Checkpoint is both a Deadline Start Checkpoint and Deadline End Checkpoint – if Deadline Supervision is chained. * Expired Supervision Cycle: A Supervision Cycle where the alive-supervision has failed its two escalation steps (Alive Counter fails the expected amount of Alive Indications (including tolerances) more often than the allowed amount of failed reference cycles). * Failed Supervision Reference Cycle: A Supervision Reference Cycle that ends with a detected deviation (including tolerances) between the Alive Counter and the expected amount of Alive Indications. * Global Supervision Status: Status that summarizes the Local Supervision Status of all Supervised Entities. * Graph: A set of Checkpoints connected through Transitions, where at least one of Checkpoints is an Initial Checkpoint. There is a path (through Transitions) between any two Checkpoints of the Graph * External Graph: Graph that may involve more than one Supervised Entity. Its configuration is mode-dependent. * External Transition: An External Transition is a transition between two Checkpoints, where the Checkpoints belong to different Supervised Entities. * Local Supervision Status: Status that represents the current result of alive-supervision of a single Supervised Entity. * Logical Supervision: Kind of online supervision of software that checks if the software (Supervised Entity or set of Supervised Entities) is executed in the sequence defined by the programmer (by the developed code). * Internal Graph: Graph that may not span over several Supervised Entity. Its configuration is mode-independent and can be disabled by disabling the corresponding Supervised Entity. * Internal Transition: An I nternal Transition is a transition between two Checkpoints of a Supervised Entity. * Mode: A mode is a certain set of states of the various state machines that are running in the vehicle that are relevant to a particular entity, e.g. a SW-C, a BSW module, an application, a whole vehicle In its lifetime, an entity changes between a set of mutually exclusive modes. These changes are triggered by environmental data, e.g. signal reception, operation invocation. In the context of the Watchdog Manager a mode is defined by a set of configuration options. The set of Supervised Entities to be supervised may vary from mode to mode. * Supervised Entity: A software entity which is included in the supervision of the Watchdog Manager. Each Supervised Entity has exactly one identifier. A Supervised Entity denotes a collection of Checkpoints within a Software Component or Basic Software Module. There may be zero, one or more Supervised Entities in a Software Component or Basic Software Module. * Supervised Entity Identifier: An Identifier that identifies uniquely a Supervised Entity within an Application. * Supervision Counter: An independent data resource in context of a Supervised Entity which is updated by the Watchdog Manager during each supervision cycle and which is used by the alive-supervision algorithm to perform the check against counted Alive Indications. * Supervision Cycle: The time period of Watchdog Manager, where the cyclic Alive Supervision is performed. This is done by the main function of Watchdog Manager. * Supervision Reference Cycle: The amount of Supervision Cycles to be used as reference by the Alive Supervision to perform the check of counted Alive Indications (individually for each Supervised Entity). 415e4003c372e5ff93a75ff900d509e38bfa76fe 0 558 1478 729 2014-10-22T07:11:25Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Watchdog Interface (WdgIf) is a [[Basic Software Module]] of the [[Onboard Device Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 1be5c17121ffbeb490402926d2fba80dfd49680d 0 557 1479 803 2014-10-22T07:11:31Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Watchdog [[Driver]] (Wdg) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 24adcdf02d0b7fb8858d60d7754e49fce3bb935c 0 512 1480 792 2014-10-22T07:13:06Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The TTCAN [[Driver]] (Ttcan) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 6de6e628bdf993dc89e9810909212cabb0dd0292 0 522 1481 693 2014-10-22T07:13:13Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The TTCAN Interface (TtcanIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 115aeae7cfe12916a2bb471caf5776951351b91a 0 382 1482 460 2014-10-22T07:13:18Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The trigger [[interface]] allows [[Software Components]] to trigger the execution of other software components. The purpose of the trigger interface is to allow for fast response times with regards to the occurrence of a trigger which might occur sporadic or at a variable cycle time. Example: triggering based on the crank shaft and cam shaft position. 638b2d3f45b12e0fc988eaebf269c4a227417711 0 614 1483 1044 2014-10-22T07:13:26Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[AUTOSAR]] defines types and prototypes. This concept allows re-using elements (like [[Software Component]]s, [[Data Type]]s) several times. E.g. a SW-C type defines the properties of the SW-C together with the [[port]]s, [[internal behavior]] etc. The SW-C prototype is the usage of a SW-C type. The prototype contains all elements and properties of the type plus additional properties such as the shortName. A prototype is referencing a type and reuses its properties. In analogy to C++ the type would be the class and the prototype the instantiation of this class. 26f9f8df5592e270e41bd305e07d15aad05ce97b 0 538 1484 709 2014-10-22T07:13:29Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The UDP Network Management (UdpNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 5a317acd2ff0b9efb84ec094e643cbb8745f6ebc 0 355 1485 414 2014-10-22T07:13:32Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[VFB]] View describes [[system]]s or subsystems in the car independently of these resources; in other words, independently of: -what kind of and how many [[ECU]]s are present in the car -on what ECUs the entities in the VFB-View run -how the ECUs are interconnected: what kind of network technology ([[CAN]], [[LIN]],…) and what kind of [[topology]] (presence of [[gateway]]s) is used. In the VFB-View, the system or [[subsystem]] under consideration is a [[Composition]] which consists out of [[Connector]]s and [[Component]]s. 17aa9548911468242f2885afa2f159a199dae1ea 0 348 1486 406 2014-10-22T07:13:35Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Adaptation of [[SW]] by selection of functional alternatives according to external requirements (e.g. country-dependent or legal restrictions). The major difference with [[calibration]] is that this later doesn’t aim to adapt the SW functionality itself but only aims to adjust the SW to the HW/SW environment, e.g. the calibration of engine control SW that is adjusted to the physical parameters of every engine. Variant Coding also includes [[vehicle-specific]] (not [[user-specific]]) SW adaptation due to end-customer wishes (e.g. deactivation of speed-dependent automatic locking). Variant Coding is always done after compile time. Used techniques to select variants include end-of-line programming and garage programming. ba34b37f8d89da78ff89ca41fa0d9385b375aa46 0 356 1487 1022 2014-10-22T07:13:39Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Virtual Functional Bus is an abstraction of the communication between [[Atomic Software Component]]s and [[AUTOSAR Service]]s. This abstraction is such that specification of the communication mechanisms is independent from the concrete technology chosen to realize the communication. After compilation and linking of software for a dedicated [[ECU]] the Virtual Functional Bus interfaces are realized by the AUTOSAR [[Runtime Environment]]. abc6f79543014b7f95b99ebeba8a33c92cb1cd1e 0 535 1488 706 2014-10-22T07:15:24Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The PDU Router (PduR) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 110b90e53e7db737212e484dad0ce4490ad336a6 0 513 1489 808 2014-10-22T07:15:27Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The SPI [[Handler]] [[Driver]] (Spi) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 5c9f3677e1a8bd44f4d64d6e62d48eab9bcee317 0 423 1490 544 2014-10-22T07:30:34Z Oliver 1 Redirected page to [[Interface#Client-Server Interface]] wikitext text/x-wiki #REDIRECT [[Interface#Client-Server Interface]] c4f259cc550501302b29f5bc4b54a15dc68e5a24 0 284 1491 332 2014-10-22T07:31:48Z Oliver 1 Redirected page to [[Port#Provide Port]] wikitext text/x-wiki #REDIRECT [[Port#Provide Port]] f05748abf975ccfc134da01abe9abdfb75063b4d 0 291 1492 339 2014-10-22T07:31:57Z Oliver 1 Redirected page to [[Port#Require Port]] wikitext text/x-wiki #REDIRECT [[Port#Require Port]] c2e8b8af528861a4d0cf01cbe24afbb5602b81de 0 378 1493 446 2014-10-22T07:33:03Z Oliver 1 Redirected page to [[Sensor-Actuator Software Component]] wikitext text/x-wiki #REDIRECT [[Sensor-Actuator Software Component]] 21a1e7ee711227d0bfbfce5deaf404cce2145777 0 691 1494 1068 2014-10-22T07:33:58Z Oliver 1 Redirected page to [[Interface#Client-Server Interface]] wikitext text/x-wiki #REDIRECT [[Interface#Client-Server Interface]] c4f259cc550501302b29f5bc4b54a15dc68e5a24 0 690 1495 1067 2014-10-22T07:34:01Z Oliver 1 Redirected page to [[Interface#Client-Server Interface]] wikitext text/x-wiki #REDIRECT [[Interface#Client-Server Interface]] c4f259cc550501302b29f5bc4b54a15dc68e5a24 0 424 1496 545 2014-10-22T07:35:46Z Oliver 1 Redirected page to [[Port#Client-Server Port]] wikitext text/x-wiki #REDIRECT [[Port#Client-Server Port]] 24d3ced79c0c827f6a685d55e716cc843bd12acf 0 886 1497 2014-10-23T10:37:00Z Oliver 1 Redirected page to [[Event Data Recorder]] wikitext text/x-wiki #REDIRECT [[Event Data Recorder]] 261ad012cd0e7ca732d1e7f2304637595481e980 0 887 1498 2014-10-23T10:37:35Z Oliver 1 Redirected page to [[Electronic Parking Brake]] wikitext text/x-wiki #REDIRECT [[Electronic Parking Brake]] bff3bfb15bd0b0eb25fc2521eeaebe4d4780540b 0 888 1499 2014-10-23T10:38:08Z Oliver 1 Redirected page to [[Electronic Power Steering]] wikitext text/x-wiki #REDIRECT [[Electronic Power Steering]] cc88b6ec52610b85763685faeed73ee520d609af 0 159 1500 1352 2014-10-23T10:39:15Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ESC, ESP || Electronic Stability Control || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |- |LSM || Light Switch Module || |- |RSM || Rain Sensor Module || |- |TBM || Trailer Brake Module || |- |TRM || Trailer Module || |- |AFS || Active Front Steering<br>Advanced Frontlighting System || |- |TCS || Traction Control System || |- |ACC || Adaptive Cruise Control || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 83fee6f4a2efe173055fcd79ad13f4e14b7b3c2a 0 889 1501 2014-10-23T10:39:31Z Oliver 1 Redirected page to [[Electronic Control Unit#ESC]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#ESC]] 27eb28d1239ff2564771bb95d1a535f84d5cebdf 0 890 1502 2014-10-23T10:40:11Z Oliver 1 Redirected page to [[Funktionale Sicherheit]] wikitext text/x-wiki #REDIRECT [[Funktionale Sicherheit]] 76e7eb083bbc31fe8e3b811ab650342b752ddeb8 0 891 1503 2014-10-23T10:40:42Z Oliver 1 Redirected page to [[Head-Up Display]] wikitext text/x-wiki #REDIRECT [[Head-Up Display]] 2ee4f452591a0365758fec3b162696eea868a8e8 0 892 1504 2014-10-23T11:41:57Z Oliver 1 Redirected page to [[Terminal Designation]] wikitext text/x-wiki #REDIRECT [[Terminal Designation]] 1dbcd534e04fdb4422f434cf0edadae4a8676d96 0 893 1505 2014-10-23T14:16:06Z Oliver 1 Redirected page to [[Terminal Designation]] wikitext text/x-wiki #REDIRECT [[Terminal Designation]] 1dbcd534e04fdb4422f434cf0edadae4a8676d96 0 894 1506 2014-10-23T14:25:49Z Oliver 1 Created page with "The terminal designation system for automotive electrical systems is specified by DIN 72552. {| class="wikitable" |Terminal || Description || German Description |- | 1 || Ign..." wikitext text/x-wiki The terminal designation system for automotive electrical systems is specified by DIN 72552. {| class="wikitable" |Terminal || Description || German Description |- | 1 || Ignition coil / distributor low voltage || |- | 1a || Ignition coil / distributor low voltage - contact breaker I || |- | 1b || Ignition coil / distributor low voltage - contact breaker II || |- | 4 || Ignition coil / distributor high voltage || |- | 4a || Ignition coil / distributor high voltage - ignition coil I || |- | 4b || Ignition coil / distributor high voltage - ignition coil II || |- | 15 || Switched (+) ignition / starting switch || |- | 15a || Output on series resistor to ignition coil and to starter motor || |- | 17 || Glow-plug and starter switch Start || |- | 19 || Glow-plug and starter switch Preheat || |- | 30 || Battery positive (+) || |- | 30a || Battery changeover 12V/24V <br> Input from battery II positive (+) || |- | 31 || Battery negative, Ground (-) || |- | 31a || Battery II negative, Ground (-) || |- | 31b || Battery negative, Ground (-) <br> via switch or relay || |- | 31c || Battery I negative, Ground (-) || |- | 32 || Electric motors return line || |- | 33 || Electric motors main terminal || |- | 33a || Self-parking switchoff || |- | 33b || Shunt field || |- | 33f || For second lower-speed level || |- | 33g || For third lower-speed level || |- | 33h || For fourth lower-speed level || |- | 33L || Counterclockwise rotation || |- | 33R || Clockwise rotation || |- | 45 || Separate starter relay, output <br> starter, input (primary current) || |- | 45a || Output starter I <br> Input starters I and II || |- | 45b || Output starter II || |- | 48 || Terminal on starter and on start-repeating relay for monitoring starting procedure || |- | 49 || Turn signal flashers Input || |- | 49a || Turn signal flashers Output || |- | 49b || Turn signal flashers Output, second flasher circuit || |- | 49c || Turn signal flashers Output, third flasher circuit || |- | 50 || Starter control direct || |- | 50a || Starter battery changeover relay <br> output for starter control || |- | 50b || Starter control for parallel operation of two starters with sequential control || |- | 50c || Input to starting relay for starter I || |- | 50d || || |- | 50e || || |- | 50f || || |- | 50g || || |- | 50h || || |- | 53 || || |- | 53a || || |- | 53b || || |- | 53c || || |- | 53e || || |- | 53i || || |- | 55 || || |- | 56 || || |- | 56a || || |- | 56b || || |- | 56d || || |- | 57a || || |- | 57L || || |- | 57R || || |- | 58 || || |- | 58L || || |- | 58R || || |- | 61 || || |- | 75 || || |- | 76 || || |- | 81 || || |- | 81a || || |- | 81b || || |- | 82 || || |- | 82a || || |- | 82b || || |- | 82z || || |- | 82y || || |- | 83 || || |- | 83a || || |- | 83b || || |- | 83L || || |- | 83R || || |- | 84 || || |- | 84a || || |- | 84b || || |- | 85 || || |- | 86 || || |- | 86a || || |- | 86b || || |- | 87 || || |- | 87a || || |- | 87b || || |- | 87c || || |- | 87z || || |- | 87y || || |- | 87x || || |- | 88 || || |- | 88a || || |- | 88b || || |- | 88c || || |- | 88z || || |- | 88y || || |- | 88x || || |} f79636efad590420a324697eb8854c31de9b98a2 1507 1506 2014-10-23T14:41:51Z Oliver 1 wikitext text/x-wiki The terminal designation system for automotive electrical systems is specified by DIN 72552. {| class="wikitable" |Terminal || Description || German Description |- | 1 || Ignition coil / distributor low voltage || |- | 1a || Ignition coil / distributor low voltage - contact breaker I || |- | 1b || Ignition coil / distributor low voltage - contact breaker II || |- | 4 || Ignition coil / distributor high voltage || |- | 4a || Ignition coil / distributor high voltage - ignition coil I || |- | 4b || Ignition coil / distributor high voltage - ignition coil II || |- | 15 || Switched (+) ignition / starting switch || |- | 15a || Output on series resistor to ignition coil and to starter motor || |- | 17 || Glow-plug and starter switch Start || |- | 19 || Glow-plug and starter switch Preheat || |- | 30 || Battery positive (+) || |- | 30a || Battery changeover 12V/24V <br> Input from battery II positive (+) || |- | 31 || Battery negative, Ground (-) || |- | 31a || Battery II negative, Ground (-) || |- | 31b || Battery negative, Ground (-) <br> via switch or relay || |- | 31c || Battery I negative, Ground (-) || |- | 32 || Electric motors return line || |- | 33 || Electric motors main terminal || |- | 33a || Self-parking switchoff || |- | 33b || Shunt field || |- | 33f || For second lower-speed level || |- | 33g || For third lower-speed level || |- | 33h || For fourth lower-speed level || |- | 33L || Counterclockwise rotation || |- | 33R || Clockwise rotation || |- | 45 || Separate starter relay, output <br> starter, input (primary current) || |- | 45a || Output starter I <br> Input starters I and II || |- | 45b || Output starter II || |- | 48 || Terminal on starter and on start-repeating relay for monitoring starting procedure || |- | 49 || Turn signal flashers Input || |- | 49a || Turn signal flashers Output || |- | 49b || Turn signal flashers Output, second flasher circuit || |- | 49c || Turn signal flashers Output, third flasher circuit || |- | 50 || Starter control direct || |- | 50a || Starter battery changeover relay <br> output for starter control || |- | 50b || Starter control for parallel operation of two starters with sequential control || |- | 50c || Input to starting relay for starter I || |- | 50d || Input to starting relay for starter II || |- | 50e || Start-lock relay Input || |- | 50f || Start-lock relay Output || |- | 50g || Start-repeat relay Input || |- | 50h || Start-repeat relay Output || |- | 53 || Wiper motor input (+) || |- | 53a || Wiper (+) self parking || |- | 53b || Wiper shunt winding || |- | 53c || Electric windshield washer pump || |- | 53e || Wiper break winding || |- | 53i || Wiper motor with permanent magnet and third brush (for higher speed) || |- | 55 || Fog lamp || |- | 56 || Headlamp || |- | 56a || High beam and high beam indicator || |- | 56b || Low beam || |- | 56d || Headlamp flasher contact || |- | 57a || Parking lamp || |- | 57L || Parking lamp, Left || |- | 57R || Parking lamp, Right || |- | 58 || lamps for Side-marker, tail, license-plate, instrument panel || |- | 58L || lamps for Side-marker, tail, license-plate, instrument panel, Left || |- | 58R || lamps for Side-marker, tail, license-plate, instrument panel, Right || |- | 61 || Alternator charge indicator lamp || |- | 75 || Tuner (radio), cigarette lighter || |- | 76 || Loudspeakers || |- | 81 || || |- | 81a || || |- | 81b || || |- | 82 || || |- | 82a || || |- | 82b || || |- | 82z || || |- | 82y || || |- | 83 || || |- | 83a || || |- | 83b || || |- | 83L || || |- | 83R || || |- | 84 || || |- | 84a || || |- | 84b || || |- | 85 || || |- | 86 || || |- | 86a || || |- | 86b || || |- | 87 || || |- | 87a || || |- | 87b || || |- | 87c || || |- | 87z || || |- | 87y || || |- | 87x || || |- | 88 || || |- | 88a || || |- | 88b || || |- | 88c || || |- | 88z || || |- | 88y || || |- | 88x || || |} b1114a7bd6b14ae759760d0fba4911e31f612f97 1508 1507 2014-10-23T20:04:14Z Oliver 1 wikitext text/x-wiki The terminal designation system for automotive electrical systems is specified by DIN 72552. {| class="wikitable" |Terminal || Description || German Description |- | 1 || Ignition coil / distributor low voltage || Zündspule Niederspannung |- | 1a || Ignition coil / distributor low voltage - contact breaker I || |- | 1b || Ignition coil / distributor low voltage - contact breaker II || |- | 4 || Ignition coil / distributor high voltage || Zündspule Hochspannung |- | 4a || Ignition coil / distributor high voltage - ignition coil I || von Zündspule I, Klemme 4 |- | 4b || Ignition coil / distributor high voltage - ignition coil II || von Zündspule II, Klemme 4 |- | 15 || Switched (+) ignition / starting switch || Geschaltetes Plus hinter Batterie (Ausgang Zündschalter) |- | 15a || Output on series resistor to ignition coil and to starter motor || Ausgang am Vorwiderstand Zündspule und zum Starter |- | 17 || Glow-plug and starter switch Start || Glühstartschalter Starten |- | 19 || Glow-plug and starter switch Preheat || Glühstartschalter Vorglühen |- | 30 || Battery positive (+) || Eingang von Batterie Plus (direct) |- | 30a || Battery changeover 12V/24V <br> Input from battery II positive (+) || Batterieumschaltung 12V/24V <br> Eingang von Batterie II Plus |- | 31 || Battery negative, Ground (-) || Rückleitung ab Batterie <br> Minus oder Masse (direct) |- | 31a || Battery II negative, Ground (-) || Rückleitung an Batterie II Minus |- | 31b || Battery negative, Ground (-) <br> via switch or relay || Rückleitung an Batterie Minus oder Masse über Schalter oder Relais (geschaltetes Minus) |- | 31c || Battery I negative, Ground (-) || Rückleitung an Batterie I Minus |- | 32 || Electric motors return line || Elektromotoren Rückleitung |- | 33 || Electric motors main terminal || Elektromotoren Hauptanschluss |- | 33a || Electric motors Self-parking switchoff || Elektromotoren Endabstellung |- | 33b || Shunt field || Nebenschlussfeld |- | 33f || For second lower-speed level || für zweite kleinere Drehzahlstufe |- | 33g || For third lower-speed level || für dritte kleinere Drehzahlstufe |- | 33h || For fourth lower-speed level || für vierte kleinere Drehzahlstufe |- | 33L || Counterclockwise rotation || Drehrichtung links |- | 33R || Clockwise rotation || Drehrichtung rechts |- | 45 || Separate starter relay, output <br> starter, input (primary current) || Starter getrenntes Starterrelais |- | 45a || Output starter I <br> Input starters I and II || Zwei-Starter-Parallelbetrieb Startrelais für Einrückstrom |- | 45b || Output starter II || Ausgang Starter II |- | 48 || Terminal on starter and on start-repeating relay for monitoring starting procedure || Klemme am Starter und Startwiederholrelais (Überwachung des Startvorgangs) |- | 49 || Turn signal flashers Input || Blinkgeber Eingang |- | 49a || Turn signal flashers Output || Blinkgeber Ausgang |- | 49b || Turn signal flashers Output, second flasher circuit || Blinkgeber Ausgang zweiter Blinkkreis |- | 49c || Turn signal flashers Output, third flasher circuit || Blinkgeber Ausgang dritter Blinkkreis |- | 50 || Starter control direct || Startersteuerung (direct) |- | 50a || Starter battery changeover relay <br> output for starter control || Batterieumschaltrelais Ausgang für Startersteuerung |- | 50b || Starter control for parallel operation of two starters with sequential control || Startersteuerung bei Parallelbetrieb von zwei Startern mit Folgesteuerung |- | 50c || Input to starting relay for starter I || Eingang in Starterrelais für Starter I |- | 50d || Input to starting relay for starter II || Eingang in Starterrelais für Starter II |- | 50e || Start-lock relay Input || Startsperrrelais Eingang |- | 50f || Start-lock relay Output || Startsperrrelais Ausgang |- | 50g || Start-repeat relay Input || Startwiederholrelais Eingang |- | 50h || Start-repeat relay Output || Startwiederholrelais Ausgang |- | 53 || Wiper motor input (+) || Wischermotoren Eingang (+) |- | 53a || Wiper (+) self parking || Wischer (+) Endabstellung |- | 53b || Wiper shunt winding || Wischer (Nebenschlusswicklung) |- | 53c || Electric windshield washer pump || Elektrische Scheibenspülerpumpe |- | 53e || Wiper break winding || Wischer (Bremswicklung) |- | 53i || Wiper motor with permanent magnet and third brush (for higher speed) || Wischermotor mit Permanentmagnet und dritter Bürste (für höhere Geschwindigkeit) |- | 55 || Fog lamp || Nebelscheinwerfer |- | 56 || Headlamp || Scheinwerfer |- | 56a || High beam and high beam indicator || Fernlicht und Fernlichtkontrolle |- | 56b || Low beam || Abblendlicht |- | 56d || Headlamp flasher contact || Lichthupenkontakt |- | 57a || Parking lamp || Parklicht |- | 57L || Parking lamp, Left || Parklicht links |- | 57R || Parking lamp, Right || Parklicht rechts |- | 58 || lamps for Side-marker, tail, license-plate, instrument panel || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte |- | 58L || lamps for Side-marker, tail, license-plate, instrument panel, Left || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte links |- | 58R || lamps for Side-marker, tail, license-plate, instrument panel, Right || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte rechts |- | 61 || Alternator charge indicator lamp || Generatorkontrolle |- | 75 || Tuner (radio), cigarette lighter || Radio, Zigarettenanzünder |- | 76 || Loudspeakers || Lautsprecher |- | 81 || || |- | 81a || || |- | 81b || || |- | 82 || || |- | 82a || || |- | 82b || || |- | 82z || || |- | 82y || || |- | 83 || || |- | 83a || || |- | 83b || || |- | 83L || || |- | 83R || || |- | 84 || || |- | 84a || || |- | 84b || || |- | 85 || || |- | 86 || || |- | 86a || || |- | 86b || || |- | 87 || || |- | 87a || || |- | 87b || || |- | 87c || || |- | 87z || || |- | 87y || || |- | 87x || || |- | 88 || || |- | 88a || || |- | 88b || || |- | 88c || || |- | 88z || || |- | 88y || || |- | 88x || || |} 76a0fd0e4c49091c2901c77e3f67fb9dc257c65d 1513 1508 2015-02-02T14:45:19Z Oliver 1 wikitext text/x-wiki The terminal designation system for automotive electrical systems is specified by DIN 72552. {| class="wikitable" |Terminal || Description || German Description |- | 1 || Ignition coil / distributor low voltage || Zündspule Niederspannung |- | 1a || Ignition coil / distributor low voltage - contact breaker I || |- | 1b || Ignition coil / distributor low voltage - contact breaker II || |- | 4 || Ignition coil / distributor high voltage || Zündspule Hochspannung |- | 4a || Ignition coil / distributor high voltage - ignition coil I || von Zündspule I, Klemme 4 |- | 4b || Ignition coil / distributor high voltage - ignition coil II || von Zündspule II, Klemme 4 |- | 15 || Switched (+) ignition / starting switch || Geschaltetes Plus hinter Batterie (Ausgang Zündschalter) |- | 15a || Output on series resistor to ignition coil and to starter motor || Ausgang am Vorwiderstand Zündspule und zum Starter |- | 17 || Glow-plug and starter switch Start || Glühstartschalter Starten |- | 19 || Glow-plug and starter switch Preheat || Glühstartschalter Vorglühen |- | 30 || Battery positive (+) || Eingang von Batterie Plus (direct) |- | 30a || Battery changeover 12V/24V <br> Input from battery II positive (+) || Batterieumschaltung 12V/24V <br> Eingang von Batterie II Plus |- | 31 || Battery negative, Ground (-) || Rückleitung ab Batterie <br> Minus oder Masse (direct) |- | 31a || Battery II negative, Ground (-) || Rückleitung an Batterie II Minus |- | 31b || Battery negative, Ground (-) <br> via switch or relay || Rückleitung an Batterie Minus oder Masse über Schalter oder Relais (geschaltetes Minus) |- | 31c || Battery I negative, Ground (-) || Rückleitung an Batterie I Minus |- | 32 || Electric motors return line || Elektromotoren Rückleitung |- | 33 || Electric motors main terminal || Elektromotoren Hauptanschluss |- | 33a || Electric motors Self-parking switchoff || Elektromotoren Endabstellung |- | 33b || Shunt field || Nebenschlussfeld |- | 33f || For second lower-speed level || für zweite kleinere Drehzahlstufe |- | 33g || For third lower-speed level || für dritte kleinere Drehzahlstufe |- | 33h || For fourth lower-speed level || für vierte kleinere Drehzahlstufe |- | 33L || Counterclockwise rotation || Drehrichtung links |- | 33R || Clockwise rotation || Drehrichtung rechts |- | 40 || 48V supply || Versorgungsspannung 48V |- | 40 || 48V ground || Masseanschmuss 48V |- | 45 || Separate starter relay, output <br> starter, input (primary current) || Starter getrenntes Starterrelais |- | 45a || Output starter I <br> Input starters I and II || Zwei-Starter-Parallelbetrieb Startrelais für Einrückstrom |- | 45b || Output starter II || Ausgang Starter II |- | 48 || Terminal on starter and on start-repeating relay for monitoring starting procedure || Klemme am Starter und Startwiederholrelais (Überwachung des Startvorgangs) |- | 49 || Turn signal flashers Input || Blinkgeber Eingang |- | 49a || Turn signal flashers Output || Blinkgeber Ausgang |- | 49b || Turn signal flashers Output, second flasher circuit || Blinkgeber Ausgang zweiter Blinkkreis |- | 49c || Turn signal flashers Output, third flasher circuit || Blinkgeber Ausgang dritter Blinkkreis |- | 50 || Starter control direct || Startersteuerung (direct) |- | 50a || Starter battery changeover relay <br> output for starter control || Batterieumschaltrelais Ausgang für Startersteuerung |- | 50b || Starter control for parallel operation of two starters with sequential control || Startersteuerung bei Parallelbetrieb von zwei Startern mit Folgesteuerung |- | 50c || Input to starting relay for starter I || Eingang in Starterrelais für Starter I |- | 50d || Input to starting relay for starter II || Eingang in Starterrelais für Starter II |- | 50e || Start-lock relay Input || Startsperrrelais Eingang |- | 50f || Start-lock relay Output || Startsperrrelais Ausgang |- | 50g || Start-repeat relay Input || Startwiederholrelais Eingang |- | 50h || Start-repeat relay Output || Startwiederholrelais Ausgang |- | 53 || Wiper motor input (+) || Wischermotoren Eingang (+) |- | 53a || Wiper (+) self parking || Wischer (+) Endabstellung |- | 53b || Wiper shunt winding || Wischer (Nebenschlusswicklung) |- | 53c || Electric windshield washer pump || Elektrische Scheibenspülerpumpe |- | 53e || Wiper break winding || Wischer (Bremswicklung) |- | 53i || Wiper motor with permanent magnet and third brush (for higher speed) || Wischermotor mit Permanentmagnet und dritter Bürste (für höhere Geschwindigkeit) |- | 55 || Fog lamp || Nebelscheinwerfer |- | 56 || Headlamp || Scheinwerfer |- | 56a || High beam and high beam indicator || Fernlicht und Fernlichtkontrolle |- | 56b || Low beam || Abblendlicht |- | 56d || Headlamp flasher contact || Lichthupenkontakt |- | 57a || Parking lamp || Parklicht |- | 57L || Parking lamp, Left || Parklicht links |- | 57R || Parking lamp, Right || Parklicht rechts |- | 58 || lamps for Side-marker, tail, license-plate, instrument panel || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte |- | 58L || lamps for Side-marker, tail, license-plate, instrument panel, Left || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte links |- | 58R || lamps for Side-marker, tail, license-plate, instrument panel, Right || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte rechts |- | 61 || Alternator charge indicator lamp || Generatorkontrolle |- | 75 || Tuner (radio), cigarette lighter || Radio, Zigarettenanzünder |- | 76 || Loudspeakers || Lautsprecher |- | 81 || || |- | 81a || || |- | 81b || || |- | 82 || || |- | 82a || || |- | 82b || || |- | 82z || || |- | 82y || || |- | 83 || || |- | 83a || || |- | 83b || || |- | 83L || || |- | 83R || || |- | 84 || || |- | 84a || || |- | 84b || || |- | 85 || || |- | 86 || || |- | 86a || || |- | 86b || || |- | 87 || || |- | 87a || || |- | 87b || || |- | 87c || || |- | 87z || || |- | 87y || || |- | 87x || || |- | 88 || || |- | 88a || || |- | 88b || || |- | 88c || || |- | 88z || || |- | 88y || || |- | 88x || || |} 1d6d11a56aefed5f83ea30cc042dc87eeee1f1bc 1514 1513 2015-02-02T14:45:33Z Oliver 1 wikitext text/x-wiki The terminal designation system for automotive electrical systems is specified by DIN 72552. {| class="wikitable" |Terminal || Description || German Description |- | 1 || Ignition coil / distributor low voltage || Zündspule Niederspannung |- | 1a || Ignition coil / distributor low voltage - contact breaker I || |- | 1b || Ignition coil / distributor low voltage - contact breaker II || |- | 4 || Ignition coil / distributor high voltage || Zündspule Hochspannung |- | 4a || Ignition coil / distributor high voltage - ignition coil I || von Zündspule I, Klemme 4 |- | 4b || Ignition coil / distributor high voltage - ignition coil II || von Zündspule II, Klemme 4 |- | 15 || Switched (+) ignition / starting switch || Geschaltetes Plus hinter Batterie (Ausgang Zündschalter) |- | 15a || Output on series resistor to ignition coil and to starter motor || Ausgang am Vorwiderstand Zündspule und zum Starter |- | 17 || Glow-plug and starter switch Start || Glühstartschalter Starten |- | 19 || Glow-plug and starter switch Preheat || Glühstartschalter Vorglühen |- | 30 || Battery positive (+) || Eingang von Batterie Plus (direct) |- | 30a || Battery changeover 12V/24V <br> Input from battery II positive (+) || Batterieumschaltung 12V/24V <br> Eingang von Batterie II Plus |- | 31 || Battery negative, Ground (-) || Rückleitung ab Batterie <br> Minus oder Masse (direct) |- | 31a || Battery II negative, Ground (-) || Rückleitung an Batterie II Minus |- | 31b || Battery negative, Ground (-) <br> via switch or relay || Rückleitung an Batterie Minus oder Masse über Schalter oder Relais (geschaltetes Minus) |- | 31c || Battery I negative, Ground (-) || Rückleitung an Batterie I Minus |- | 32 || Electric motors return line || Elektromotoren Rückleitung |- | 33 || Electric motors main terminal || Elektromotoren Hauptanschluss |- | 33a || Electric motors Self-parking switchoff || Elektromotoren Endabstellung |- | 33b || Shunt field || Nebenschlussfeld |- | 33f || For second lower-speed level || für zweite kleinere Drehzahlstufe |- | 33g || For third lower-speed level || für dritte kleinere Drehzahlstufe |- | 33h || For fourth lower-speed level || für vierte kleinere Drehzahlstufe |- | 33L || Counterclockwise rotation || Drehrichtung links |- | 33R || Clockwise rotation || Drehrichtung rechts |- | 40 || 48V supply || Versorgungsspannung 48V |- | 41 || 48V ground || Masseanschmuss 48V |- | 45 || Separate starter relay, output <br> starter, input (primary current) || Starter getrenntes Starterrelais |- | 45a || Output starter I <br> Input starters I and II || Zwei-Starter-Parallelbetrieb Startrelais für Einrückstrom |- | 45b || Output starter II || Ausgang Starter II |- | 48 || Terminal on starter and on start-repeating relay for monitoring starting procedure || Klemme am Starter und Startwiederholrelais (Überwachung des Startvorgangs) |- | 49 || Turn signal flashers Input || Blinkgeber Eingang |- | 49a || Turn signal flashers Output || Blinkgeber Ausgang |- | 49b || Turn signal flashers Output, second flasher circuit || Blinkgeber Ausgang zweiter Blinkkreis |- | 49c || Turn signal flashers Output, third flasher circuit || Blinkgeber Ausgang dritter Blinkkreis |- | 50 || Starter control direct || Startersteuerung (direct) |- | 50a || Starter battery changeover relay <br> output for starter control || Batterieumschaltrelais Ausgang für Startersteuerung |- | 50b || Starter control for parallel operation of two starters with sequential control || Startersteuerung bei Parallelbetrieb von zwei Startern mit Folgesteuerung |- | 50c || Input to starting relay for starter I || Eingang in Starterrelais für Starter I |- | 50d || Input to starting relay for starter II || Eingang in Starterrelais für Starter II |- | 50e || Start-lock relay Input || Startsperrrelais Eingang |- | 50f || Start-lock relay Output || Startsperrrelais Ausgang |- | 50g || Start-repeat relay Input || Startwiederholrelais Eingang |- | 50h || Start-repeat relay Output || Startwiederholrelais Ausgang |- | 53 || Wiper motor input (+) || Wischermotoren Eingang (+) |- | 53a || Wiper (+) self parking || Wischer (+) Endabstellung |- | 53b || Wiper shunt winding || Wischer (Nebenschlusswicklung) |- | 53c || Electric windshield washer pump || Elektrische Scheibenspülerpumpe |- | 53e || Wiper break winding || Wischer (Bremswicklung) |- | 53i || Wiper motor with permanent magnet and third brush (for higher speed) || Wischermotor mit Permanentmagnet und dritter Bürste (für höhere Geschwindigkeit) |- | 55 || Fog lamp || Nebelscheinwerfer |- | 56 || Headlamp || Scheinwerfer |- | 56a || High beam and high beam indicator || Fernlicht und Fernlichtkontrolle |- | 56b || Low beam || Abblendlicht |- | 56d || Headlamp flasher contact || Lichthupenkontakt |- | 57a || Parking lamp || Parklicht |- | 57L || Parking lamp, Left || Parklicht links |- | 57R || Parking lamp, Right || Parklicht rechts |- | 58 || lamps for Side-marker, tail, license-plate, instrument panel || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte |- | 58L || lamps for Side-marker, tail, license-plate, instrument panel, Left || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte links |- | 58R || lamps for Side-marker, tail, license-plate, instrument panel, Right || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte rechts |- | 61 || Alternator charge indicator lamp || Generatorkontrolle |- | 75 || Tuner (radio), cigarette lighter || Radio, Zigarettenanzünder |- | 76 || Loudspeakers || Lautsprecher |- | 81 || || |- | 81a || || |- | 81b || || |- | 82 || || |- | 82a || || |- | 82b || || |- | 82z || || |- | 82y || || |- | 83 || || |- | 83a || || |- | 83b || || |- | 83L || || |- | 83R || || |- | 84 || || |- | 84a || || |- | 84b || || |- | 85 || || |- | 86 || || |- | 86a || || |- | 86b || || |- | 87 || || |- | 87a || || |- | 87b || || |- | 87c || || |- | 87z || || |- | 87y || || |- | 87x || || |- | 88 || || |- | 88a || || |- | 88b || || |- | 88c || || |- | 88z || || |- | 88y || || |- | 88x || || |} a9c9a68cdfea02f30ddf02bbbfd8c970225239ef 1515 1514 2015-02-02T14:45:51Z Oliver 1 wikitext text/x-wiki The terminal designation system for automotive electrical systems is specified by DIN 72552. {| class="wikitable" |Terminal || Description || German Description |- | 1 || Ignition coil / distributor low voltage || Zündspule Niederspannung |- | 1a || Ignition coil / distributor low voltage - contact breaker I || |- | 1b || Ignition coil / distributor low voltage - contact breaker II || |- | 4 || Ignition coil / distributor high voltage || Zündspule Hochspannung |- | 4a || Ignition coil / distributor high voltage - ignition coil I || von Zündspule I, Klemme 4 |- | 4b || Ignition coil / distributor high voltage - ignition coil II || von Zündspule II, Klemme 4 |- | 15 || Switched (+) ignition / starting switch || Geschaltetes Plus hinter Batterie (Ausgang Zündschalter) |- | 15a || Output on series resistor to ignition coil and to starter motor || Ausgang am Vorwiderstand Zündspule und zum Starter |- | 17 || Glow-plug and starter switch Start || Glühstartschalter Starten |- | 19 || Glow-plug and starter switch Preheat || Glühstartschalter Vorglühen |- | 30 || Battery positive (+) || Eingang von Batterie Plus (direct) |- | 30a || Battery changeover 12V/24V <br> Input from battery II positive (+) || Batterieumschaltung 12V/24V <br> Eingang von Batterie II Plus |- | 31 || Battery negative, Ground (-) || Rückleitung ab Batterie <br> Minus oder Masse (direct) |- | 31a || Battery II negative, Ground (-) || Rückleitung an Batterie II Minus |- | 31b || Battery negative, Ground (-) <br> via switch or relay || Rückleitung an Batterie Minus oder Masse über Schalter oder Relais (geschaltetes Minus) |- | 31c || Battery I negative, Ground (-) || Rückleitung an Batterie I Minus |- | 32 || Electric motors return line || Elektromotoren Rückleitung |- | 33 || Electric motors main terminal || Elektromotoren Hauptanschluss |- | 33a || Electric motors Self-parking switchoff || Elektromotoren Endabstellung |- | 33b || Shunt field || Nebenschlussfeld |- | 33f || For second lower-speed level || für zweite kleinere Drehzahlstufe |- | 33g || For third lower-speed level || für dritte kleinere Drehzahlstufe |- | 33h || For fourth lower-speed level || für vierte kleinere Drehzahlstufe |- | 33L || Counterclockwise rotation || Drehrichtung links |- | 33R || Clockwise rotation || Drehrichtung rechts |- | 40 || 48V supply || Versorgungsspannung 48V |- | 41 || 48V ground || Masseanschluss 48V |- | 45 || Separate starter relay, output <br> starter, input (primary current) || Starter getrenntes Starterrelais |- | 45a || Output starter I <br> Input starters I and II || Zwei-Starter-Parallelbetrieb Startrelais für Einrückstrom |- | 45b || Output starter II || Ausgang Starter II |- | 48 || Terminal on starter and on start-repeating relay for monitoring starting procedure || Klemme am Starter und Startwiederholrelais (Überwachung des Startvorgangs) |- | 49 || Turn signal flashers Input || Blinkgeber Eingang |- | 49a || Turn signal flashers Output || Blinkgeber Ausgang |- | 49b || Turn signal flashers Output, second flasher circuit || Blinkgeber Ausgang zweiter Blinkkreis |- | 49c || Turn signal flashers Output, third flasher circuit || Blinkgeber Ausgang dritter Blinkkreis |- | 50 || Starter control direct || Startersteuerung (direct) |- | 50a || Starter battery changeover relay <br> output for starter control || Batterieumschaltrelais Ausgang für Startersteuerung |- | 50b || Starter control for parallel operation of two starters with sequential control || Startersteuerung bei Parallelbetrieb von zwei Startern mit Folgesteuerung |- | 50c || Input to starting relay for starter I || Eingang in Starterrelais für Starter I |- | 50d || Input to starting relay for starter II || Eingang in Starterrelais für Starter II |- | 50e || Start-lock relay Input || Startsperrrelais Eingang |- | 50f || Start-lock relay Output || Startsperrrelais Ausgang |- | 50g || Start-repeat relay Input || Startwiederholrelais Eingang |- | 50h || Start-repeat relay Output || Startwiederholrelais Ausgang |- | 53 || Wiper motor input (+) || Wischermotoren Eingang (+) |- | 53a || Wiper (+) self parking || Wischer (+) Endabstellung |- | 53b || Wiper shunt winding || Wischer (Nebenschlusswicklung) |- | 53c || Electric windshield washer pump || Elektrische Scheibenspülerpumpe |- | 53e || Wiper break winding || Wischer (Bremswicklung) |- | 53i || Wiper motor with permanent magnet and third brush (for higher speed) || Wischermotor mit Permanentmagnet und dritter Bürste (für höhere Geschwindigkeit) |- | 55 || Fog lamp || Nebelscheinwerfer |- | 56 || Headlamp || Scheinwerfer |- | 56a || High beam and high beam indicator || Fernlicht und Fernlichtkontrolle |- | 56b || Low beam || Abblendlicht |- | 56d || Headlamp flasher contact || Lichthupenkontakt |- | 57a || Parking lamp || Parklicht |- | 57L || Parking lamp, Left || Parklicht links |- | 57R || Parking lamp, Right || Parklicht rechts |- | 58 || lamps for Side-marker, tail, license-plate, instrument panel || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte |- | 58L || lamps for Side-marker, tail, license-plate, instrument panel, Left || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte links |- | 58R || lamps for Side-marker, tail, license-plate, instrument panel, Right || Begrenzungs-, Schluss-, Kennzeichen und Instrumentenleuchte rechts |- | 61 || Alternator charge indicator lamp || Generatorkontrolle |- | 75 || Tuner (radio), cigarette lighter || Radio, Zigarettenanzünder |- | 76 || Loudspeakers || Lautsprecher |- | 81 || || |- | 81a || || |- | 81b || || |- | 82 || || |- | 82a || || |- | 82b || || |- | 82z || || |- | 82y || || |- | 83 || || |- | 83a || || |- | 83b || || |- | 83L || || |- | 83R || || |- | 84 || || |- | 84a || || |- | 84b || || |- | 85 || || |- | 86 || || |- | 86a || || |- | 86b || || |- | 87 || || |- | 87a || || |- | 87b || || |- | 87c || || |- | 87z || || |- | 87y || || |- | 87x || || |- | 88 || || |- | 88a || || |- | 88b || || |- | 88c || || |- | 88z || || |- | 88y || || |- | 88x || || |} ad8a270b8a5d132efe7a4e9888a1efcea995eb77 0 699 1509 1326 2014-11-03T09:58:52Z Oliver 1 wikitext text/x-wiki * [[Electronic Control Unit#SBC|Sensoric Brake Control]] * System Basis Chips (used e.g. for [[CAN Tranceiver Driver|CAN Transceiver]]s) 0dd3fd7cf84e5a20656818c0f8960976e1e6cac1 1510 1509 2014-11-03T09:59:08Z Oliver 1 wikitext text/x-wiki * [[Electronic Control Unit#SBC|Sensoric Brake Control]] * [[System Basis Chip]]s (used e.g. for [[CAN Tranceiver Driver|CAN Transceiver]]s) bc84a47d4f09fb36d955a1496fa1dff6b09079a6 0 895 1511 2014-11-19T10:21:42Z Oliver 1 Redirected page to [[Shared Memory Communicator]] wikitext text/x-wiki #REDIRECT [[Shared Memory Communicator]] ff7447d6e396db2b78e63419510088d6a02a5e00 0 65 1512 68 2014-11-19T10:22:05Z Oliver 1 Redirected page to [[Memory Protection Unit]] wikitext text/x-wiki #REDIRECT [[Memory Protection Unit]] eb0c045be4a7066cfbcd7528d53f013734be9d3e 0 896 1516 2015-02-02T15:27:04Z Oliver 1 Redirected page to [[Begin Of Life]] wikitext text/x-wiki #REDIRECT [[Begin Of Life]] dc77182f1cb72de2f8dd0eb944726006e7f6001c 0 897 1517 2015-02-02T15:28:03Z Oliver 1 Redirected page to [[Critical Parts Management]] wikitext text/x-wiki #REDIRECT [[Critical Parts Management]] 66f0cf3b54b11431b6d7cbb6e1f8aa9184db5773 0 898 1518 2015-02-20T08:55:29Z Oliver 1 Redirected page to [[Suspect Parameter Number]] wikitext text/x-wiki #REDIRECT [[Suspect Parameter Number]] 7e14e96737a361db2821ffde1f07c54e95801393 0 899 1519 2015-02-20T09:12:07Z Oliver 1 Created page with "The Suspect Parameter Number (SPN) is used in [[SAE J1939]] protocol for specifying DTCs that are provided in the [[DM1]] and [[DM4]] diagnostic messages for SAE J1939 On-boar..." wikitext text/x-wiki The Suspect Parameter Number (SPN) is used in [[SAE J1939]] protocol for specifying DTCs that are provided in the [[DM1]] and [[DM4]] diagnostic messages for SAE J1939 On-board diagnostic. 83cf8f8982b9a48383c333e467e927f200b8e5eb 0 900 1520 2015-04-16T18:58:57Z Oliver 1 Created page with "Large, huge Memory model configuration of the microcontroller’s compiler. By default, all access mechanisms are using extended/paged addressing. Some compilers are using the..." wikitext text/x-wiki Large, huge Memory model configuration of the microcontroller’s compiler. By default, all access mechanisms are using extended/paged addressing. Some compilers are using the term ‘huge’ instead of ‘far’. 9bee744dc0d85a08b1eb15056c3a4dcc1bb6908c 0 901 1521 2015-04-16T18:59:59Z Oliver 1 Redirected page to [[Large]] wikitext text/x-wiki #REDIRECT [[Large]] b0b0e46633a69606f7e672ccd41686d969d807b8 0 902 1522 2015-04-16T19:01:02Z Oliver 1 Created page with "Tiny, small Memory model configuration of the microcontroller’s compiler. By default, all access mechanisms are using normal addressing. Only data and code within the addres..." wikitext text/x-wiki Tiny, small Memory model configuration of the microcontroller’s compiler. By default, all access mechanisms are using normal addressing. Only data and code within the addressing range of the platform’s architecture is reachable (e.g. 64k on a 16 bit architecture). 1f0fa89c76b56705080e05196ef6bfff672c7032 1523 1522 2015-04-16T19:02:00Z Oliver 1 Redirected page to [[Small]] wikitext text/x-wiki #REDIRECT [[Small]] 524d5596bd02e934cce36595fce157d1b553a13e 0 903 1524 2015-04-16T19:02:21Z Oliver 1 Created page with "Tiny, small Memory model configuration of the microcontroller’s compiler. By default, all access mechanisms are using normal addressing. Only data and code within the addre..." wikitext text/x-wiki Tiny, small Memory model configuration of the microcontroller’s compiler. By default, all access mechanisms are using normal addressing. Only data and code within the addressing range of the platform’s architecture is reachable (e.g. 64k on a 16 bit architecture). fee19c7f087312c869bc82c9bffa5abf1e58fef9 0 904 1525 2015-04-16T19:04:37Z Oliver 1 Created page with "Compiler keyword for extended/paged addressing scheme (for data and code that may be outside the normal addressing scheme of the platform’s architecture). Some compilers ar..." wikitext text/x-wiki Compiler keyword for extended/paged addressing scheme (for data and code that may be outside the normal addressing scheme of the platform’s architecture). Some compilers are using the term ‘[[huge]]’ instead of ‘far’. b82f0c28b6c19be8d21896ecc978223c4a51aa82 0 905 1526 2015-05-20T08:12:16Z Oliver 1 Created page with "{| class="wikitable" !Service ID (hex) !Service !Description |- | 0x10 || Diagnostic Session Control | |- | 0x11 || ECU Reset | |- | 0x14 || Clear Diagnostic Information | ..." wikitext text/x-wiki {| class="wikitable" !Service ID (hex) !Service !Description |- | 0x10 || Diagnostic Session Control | |- | 0x11 || ECU Reset | |- | 0x14 || Clear Diagnostic Information | |- | 0x19 || Read DTC Information | |- | 0x22 || Read Data By Identifier | |- | 0x23 || Read Memory By Address | |- | 0x27 || Security Access | |- | 0x28 || Communication Control | |- | 0x2E || Write Data By Identifier | |- | 0x2F || Input Output Control By Identifier | |- | 0x31 || Routine Control | |- | 0x34 || Request Download | |- | 0x35 || Request Upload | |- | 0x36 || Transfer Data | |- | 0x37 || Transfer Exit | |- | 0x3D || Write Memory By Address | |- | 0x3E || Tester Present | |- | 0x85 || Control DTC Setting | |} d4bbd11f1459f5c8d291093aec7eccdbb29ed3f0 0 906 1527 2015-10-08T09:13:02Z Oliver 1 Created page with "Entity identifier see [[DoIP]]" wikitext text/x-wiki Entity identifier see [[DoIP]] ccb51005d8583f30921cace1623a4b0df10e4afc 0 907 1528 2015-10-08T09:13:58Z Oliver 1 Created page with "Group Identifier see [[DoIP]]" wikitext text/x-wiki Group Identifier see [[DoIP]] 3a71f430bc8923b6c8ba3aac1ce51d9273a8297b 0 908 1529 2015-10-13T07:54:22Z Oliver 1 Created page with "The ISO 26262 "Road vehicles — Functional safety" consists of the following parts: * Part 1: Vocabulary * Part 2: Management of functional safety * Part 3: Concept phase * P..." wikitext text/x-wiki The ISO 26262 "Road vehicles — Functional safety" consists of the following parts: * Part 1: Vocabulary * Part 2: Management of functional safety * Part 3: Concept phase * Part 4: Product development: system level * Part 5: Product development: hardware level * Part 6: Product development: software level * Part 7: Production and operation * Part 8: Supporting processes * Part 9: ASIL-oriented and safety-oriented analyses * Part 10: Guideline on ISO 26262 b52dd3a2aeb10986c3b4efdc3a1f515680ab6878 0 908 1530 1529 2015-10-13T07:56:55Z Oliver 1 Redirected page to [[ISO 26262]] wikitext text/x-wiki #REDIRECT [[ISO 26262]] 3a1075a1c5a285e6dc063d69cc2006bdce185780 0 909 1531 2015-10-13T07:57:29Z Oliver 1 Created page with "ISO 26262 "Road vehicles — Functional safety" is the adaptation of [[IEC 61508]] to comply with needs specific to the application sector of E/E systems within road vehicles...." wikitext text/x-wiki ISO 26262 "Road vehicles — Functional safety" is the adaptation of [[IEC 61508]] to comply with needs specific to the application sector of E/E systems within road vehicles. It consists of the following parts: * Part 1: Vocabulary * Part 2: Management of functional safety * Part 3: Concept phase * Part 4: Product development: system level * Part 5: Product development: hardware level * Part 6: Product development: software level * Part 7: Production and operation * Part 8: Supporting processes * Part 9: ASIL-oriented and safety-oriented analyses * Part 10: Guideline on ISO 26262 973f61d7bdc0bb60aea69a97e28aaca6fb97fe80 0 514 1532 685 2015-11-05T19:56:53Z Oliver 1 wikitext text/x-wiki The [[wikipedia:CAN_bus|CAN]] Interface (CanIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 23835b7a22f1683afdbd555efe5eccdf439c1d4b 1534 1532 2015-11-05T19:59:18Z Oliver 1 wikitext text/x-wiki The [[wikipedia:CAN_bus|CAN]] Interface (CanIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] 3e7feb5efb6ee165ba76b9bb92a01870c7077582 0 28 1533 1313 2015-11-05T19:57:20Z Oliver 1 Redirected page to [[wikipedia:CAN bus]] wikitext text/x-wiki #REDIRECT [[wikipedia:CAN_bus|CAN]] 2a6e1a00029f592516fb372dcf327ffd8b0813fb 0 31 1535 1072 2015-11-05T20:00:46Z Oliver 1 wikitext text/x-wiki The Communication Module (COM) is a [[Basic Software Module]] of the [[Communication Services]]. Main features of the COM module are * Provision of signal oriented data interface for the [[RTE]] * Packing of AUTOSAR signals to [[I-PDU]]s to be transmitted * Unpacking of received I-PDUs and provision of received signals to RTE * [[Routing]] of signals from received I-PDUs into I-PDUs to become transmitted * Routing of signal groups from received I-PDUs into I-PDUs to become transmitted * Communication transmission control (start/ stop of I-PDU groups) * Replications of send requests * Guarantee of minimum distances between transmit I-PDUs * Monitoring of receive signals (signals timeout) * Filter mechanisms for incoming signals * Different notification mechanisms * Provision of init values and update indications * [[Byte order]] conversion * Sign extension * Support of two different transmission modes per I-PDU * Signal based gateway * Support of large and dynamic length data types * Support of I-PDU counters and I-PDU replication The AUTOSAR COM module provides the following ComFilterAlgorithms: * ALWAYS * NEVER * MASKED_NEW_EQUALS_X * MASKED_NEW_DIFFERS_X * MASKED_NEW_DIFFERS_MASKED_OLD * NEW_IS_WITHIN * NEW_IS_OUTSIDE * ONE_EVERY_N === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] 42b6a833a8a5ba05e18f9d5d29e798dcac4b780e 0 56 1536 59 2015-11-05T20:03:12Z Oliver 1 Redirected page to [[wikipedia:Local Interconnect Network]] wikitext text/x-wiki #REDIRECT [[wikipedia:Local_Interconnect_Network]] 5b752b66e42642f13375948e0075335758969f7e 0 98 1537 1153 2015-11-05T20:05:02Z Oliver 1 Redirected page to [[wikipedia:XCP (Protocol)]] wikitext text/x-wiki #REDIRECT [[wikipedia:XCP_(Protocol)]] a65d6a6b0fe5ec7157ab111c0e2e4d3c1c14e557 0 100 1538 103 2015-11-05T20:05:57Z Oliver 1 Redirected page to [[wikipedia:XML]] wikitext text/x-wiki #REDIRECT [[wikipedia:XML]] b351bffa4bcb3c01c584d4423f887071977ad32c 0 653 1539 986 2015-11-05T20:06:22Z Oliver 1 wikitext text/x-wiki Wait points are a characteristic of a [[runnable entity]] that specifies that the [[operation system]] blocks the [[runnable]] execution at the specific code position of the [[RTE macro]] until a specific [[RTE Event]] occurs. [[Category:AUTOSAR]] fded793e4d68a07fd804276317ebaabbbc14e72e 0 32 1542 35 2015-11-06T09:01:03Z Oliver 1 Redirected page to [[wikipedia:Central processing unit]] wikitext text/x-wiki #REDIRECT [[wikipedia:Central_processing_unit]] 3c93133751712a72d1ea6bce6d3e99517ecfe30a 0 876 1543 1343 2015-11-06T09:02:58Z Oliver 1 Redirected page to [[wikipedia:XML Schema (W3C)]] wikitext text/x-wiki #REDIRECT [[wikipedia:XML_Schema_(W3C)]] f9bf69d1c03cb0fbc2037556a2bbe329b4712dd2 0 911 1544 2015-11-06T09:06:00Z Oliver 1 Redirected page to [[Application Interface]] wikitext text/x-wiki #REDIRECT [[Application Interface]] a0698fda086e777bfbdaa24f4e8d3ea2b7e57e88 0 912 1545 2015-11-06T09:06:31Z Oliver 1 Redirected page to [[Critical Out of Position]] wikitext text/x-wiki #REDIRECT [[Critical Out of Position]] a6ca3e877562a9d49baf6f88ee3c9a6c42e509d1 0 913 1546 2015-11-06T09:07:18Z Oliver 1 Redirected page to [[wikipedia:ECall]] wikitext text/x-wiki #REDIRECT [[wikipedia:ECall]] 952d0ee42645f86621aabe896570648a3863cfc8 0 914 1547 2015-11-06T09:07:38Z Oliver 1 Redirected page to [[Occupant Detection]] wikitext text/x-wiki #REDIRECT [[Occupant Detection]] c8add713dcceae33b05375d7f2de871742330172 0 915 1548 2015-11-06T09:07:55Z Oliver 1 Redirected page to [[Out Of Position]] wikitext text/x-wiki #REDIRECT [[Out Of Position]] bf81a9fe092f035b3b3511a9566e6a3985232af8 0 916 1549 2015-11-06T09:08:08Z Oliver 1 Redirected page to [[Occupant and Pedestrian Safety]] wikitext text/x-wiki #REDIRECT [[Occupant and Pedestrian Safety]] d4e299618c9d64f50c474c53a0b67f043a0721f6 0 917 1550 2015-11-06T09:08:21Z Oliver 1 Redirected page to [[Occupant Restraint Activation]] wikitext text/x-wiki #REDIRECT [[Occupant Restraint Activation]] 688b55bc9112833296ded68982518659666384c9 0 918 1551 2015-11-06T09:08:34Z Oliver 1 Redirected page to [[Pedestrian Crash Detection]] wikitext text/x-wiki #REDIRECT [[Pedestrian Crash Detection]] d1d757e122f99f24d4c10ef42b5da7ebd3b1b742 0 919 1552 2015-11-06T09:08:49Z Oliver 1 Redirected page to [[Pedestrian Protection Actuator Activation]] wikitext text/x-wiki #REDIRECT [[Pedestrian Protection Actuator Activation]] b164a7a79f46b848d10037b15f6b5be12254d364 0 920 1553 2015-11-06T09:09:01Z Oliver 1 Redirected page to [[Seat Belt Reminder]] wikitext text/x-wiki #REDIRECT [[Seat Belt Reminder]] 954bf67af73cd86f3622fc736872dc443cec20d1 10 921 1554 2015-11-06T09:16:41Z Oliver 1 Created page with "[[Category:AUTOSAR]] === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] ===" wikitext text/x-wiki [[Category:AUTOSAR]] === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 6ad2d6edfd9ec8d6aad66a1f33180eef0c430ec1 0 523 1555 1385 2015-11-06T09:17:42Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:CAN_bus|CAN]] Network Management (CanNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 99d613f87ef15c0816daa33a0cd149f401cb55ef 1556 1555 2015-11-06T09:18:36Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:CAN_bus|CAN]] [[Network Management]] (CanNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 6fb03752b29d72b574777888711ed59ca6b03ef6 0 524 1557 1386 2015-11-06T09:19:36Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:CAN_bus|CAN]] [[State Manager]] (CanSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === ba70ee1a1f19b045ef8ff930f8c327e87312ff70 0 525 1558 1388 2015-11-06T09:19:58Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:CAN_bus|CAN]] [[Transport Layer]] (CanTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 0271df7532339ad7e307e09ea10238e9befdc052 0 526 1559 1400 2015-11-06T09:21:03Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:Ethernet]] [[State Manager]] (EthSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 70ae2b7c4c80dcb0670e7b64ce4079f7d800a67a 0 527 1560 1404 2015-11-06T09:21:54Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:FlexRay]] AUTOSAR [[Transport Layer]] (FrArTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 2f5dd43f171461e310a1eba9b675aa98136bd579 0 528 1561 699 2015-11-06T09:22:43Z Oliver 1 wikitext text/x-wiki The [[wikipedia:FlexRay]] [[wikipedia:International_Organization_for_Standardization|ISO]] [[Transport Layer]] (FrTp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 9effef29033fe015eedde9fc190b773d389059e3 0 529 1562 1407 2015-11-06T09:23:19Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:FlexRay]] [[Network Management]] (FrNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === c69a648e6e1bcf718ba0f48b6f70995c7ddfad14 0 530 1563 1411 2015-11-06T09:23:41Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:FlexRay]] [[State Manager]] (FrSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 0038c272d087677743acb06f9beaf8fb9da0a8f1 0 531 1564 1413 2015-11-06T09:24:35Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[I-PDU|IPDU]] Multiplexer (IpduM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === cbb8ad877ffb20dd07b32558e3fe7c5f899bad6f 0 532 1565 1418 2015-11-06T09:25:15Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:Local_Interconnect_Network|LIN]] [[Network Management]] (LinNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 54d198234358f62a74d51fc859037bfe79ae8a4d 0 533 1566 1419 2015-11-06T09:25:43Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:Local_Interconnect_Network|LIN]] [[State Manager]] (LinSM) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === cf1570fe5c6d5ca244023b636ef47061751db899 0 535 1567 1488 2015-11-06T09:26:45Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[Protocol_Data_Unit|PDU]] Router (PduR) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 96a6cdc0263795ac13ed920fc9c97e822915001e 0 536 1568 707 2015-11-06T09:27:56Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:SAE_J1939|SAE J1939]] [[Transport Layer]] (J1939Tp) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 462e43e3b9d256680ca8a620e41540f0d84cd9a3 0 538 1569 1484 2015-11-06T09:28:57Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:User_Datagram_Protocol|UDP]] [[Network Management]] (UdpNm) is a [[Basic Software Module]] of the [[Communication Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === b62da4fd6cfb51400d23d41fff725dd3de23e6d6 0 562 1570 1375 2015-11-06T09:29:43Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[ECU]] [[State Manager]] (EcuM) is a [[Basic Software Module]] of the [[System Services]]. It is responsible for the basic initialization and de-initialization of basic software components. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 5fc5325f570f28e821c9d5805330fd0177c8e54b 0 516 1571 1399 2015-11-06T09:30:31Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:Ethernet]] Interface (EthIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 30af048920482b42d4ff85c35c692155a791c177 1572 1571 2015-11-06T09:31:11Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:Ethernet|Ethernet]] Interface (EthIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 5a1471fc9a38d4ab2e887a2bae0a8d6958bab797 0 517 1573 1401 2015-11-06T09:36:14Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:Ethernet]] [[Transceiver]] Driver (EthTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === a95e382d17ab2f8217027ee210067c98f0d135e0 1574 1573 2015-11-06T09:37:46Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:Ethernet|Ethernet]] [[Transceiver]] Driver (EthTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === cbda76b751a61204407063e498601c7c4686b31a 0 518 1575 1406 2015-11-06T09:38:26Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:FlexRay|FlexRay ]] Interface (FrIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === c630ea8de057afcb36815eca67130f70c7c97a50 1576 1575 2015-11-06T09:38:46Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:FlexRay|FlexRay]] Interface (FrIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 3393b61af06ede53781fcaaba4aef1e09acf7d44 0 519 1577 1410 2015-11-06T09:38:57Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:FlexRay|FlexRay]] [[Tranceiver]] Driver (FrTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 759c14522a29ebab8ff8e2e4bf5b6d9e277768f7 0 520 1578 1417 2015-11-06T09:39:31Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:Local_Interconnect_Network|LIN]] Interface (LinIf) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === f23325e12f6a95dfb5504b4ad9a9b1f43546b295 0 521 1579 1420 2015-11-06T09:39:57Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[wikipedia:Local_Interconnect_Network|LIN]] [[Transceiver]] Driver (LinTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === e5fc09faada65840fd272b674065bc5da7ee69ba 0 551 1580 722 2015-11-06T09:43:48Z Oliver 1 wikitext text/x-wiki The [[Flash]] [[EEPROM]] Emulation (Fee) is a [[Basic Software Module]] of the [[Memory Services]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] f610b97704ef3d13794f4cd1286d733a0fd3f0bf 0 550 1581 1396 2015-11-06T09:44:04Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The [[EEPROM Abstraction]] (Ea) is a [[Basic Software Module]] of the [[Memory HW Abstraction]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === 4c66f6f6a2e25414a004294791e741ba45a4c33f 0 508 1582 1384 2015-11-06T09:44:44Z Oliver 1 wikitext text/x-wiki The [[wikipedia:CAN_bus|CAN]] [[Driver]] (Can) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] c8de2874d393e9584058a5dde2ce33903ee71d66 0 509 1583 1398 2015-11-06T09:45:25Z Oliver 1 wikitext text/x-wiki The [[wikipedia:Ethernet|Ethernet]] [[Driver]] (Eth) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] 48f8097591f6f436221a0e2dcf03b56d27af1249 0 510 1584 1405 2015-11-06T09:46:02Z Oliver 1 wikitext text/x-wiki The [[wikipedia:FlexRay|FlexRay]] [[Driver]] (Fr) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] 234eb82413f1e453f23869873345fb30ae0ae453 0 511 1585 1416 2015-11-06T09:46:44Z Oliver 1 wikitext text/x-wiki The [[wikipedia:Local_Interconnect_Network|LIN]] [[Driver]] (Lin) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] 66b856565212c7bc70ab6988ce093465ceb6a5e1 0 513 1586 1489 2015-11-06T09:47:44Z Oliver 1 wikitext text/x-wiki The [[wikipedia:Serial_Peripheral_Interface_Bus|SPI]] [[Handler]] [[Driver]] (Spi) is a [[Basic Software Module]] of the [[Communication Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] 77ad4d207ed5361292374a15776290b44ff9beec 0 546 1587 1397 2015-11-06T09:48:12Z Oliver 1 wikitext text/x-wiki The [[EEPROM]] [[Driver]] (Eep) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] 730ce01dd43b34c2646dd5fffb4cdcee8eef4f9d 0 547 1588 800 2015-11-06T09:48:48Z Oliver 1 wikitext text/x-wiki The [[Flash]] [[Driver]] (Fls) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] d3600b5d1a96e58c619e7dfbb31774d122d53d4e 0 549 1589 720 2015-11-06T09:49:06Z Oliver 1 wikitext text/x-wiki The [[Flash]] Test (FlsTst) is a [[Basic Software Module]] of the [[Memory Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] 5df1651a6fe4db38c88e6abef56bc26d732519d7 0 557 1590 1479 2015-11-06T09:49:26Z Oliver 1 wikitext text/x-wiki The [[Watchdog]] [[Driver]] (Wdg) is a [[Basic Software Module]] of the [[Microcontroller Drivers]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] 31b9f6a60af3428afc9544423edbac3898032c68 0 425 1591 546 2015-11-06T10:00:09Z Oliver 1 wikitext text/x-wiki * [[Software Requirement Specification]] * [[Safety Restraint System]] f4f36c300366ed712132445fb2d8b911dd55904a 0 922 1592 2015-11-06T10:00:25Z Oliver 1 Redirected page to [[Vehicle Crash Detection]] wikitext text/x-wiki #REDIRECT [[Vehicle Crash Detection]] 25de6695edd6c4ab315660fb2b0ababef5ba3c2e 0 923 1593 2015-11-06T10:00:38Z Oliver 1 Redirected page to [[Rollover Crash Detection]] wikitext text/x-wiki #REDIRECT [[Rollover Crash Detection]] eb93d8d69caccee8762811040c9be97cc90ad11e 0 924 1594 2015-11-06T10:00:52Z Oliver 1 Redirected page to [[Pitchover Crash Detection]] wikitext text/x-wiki #REDIRECT [[Pitchover Crash Detection]] 784e6300abdbbad4b4d3dd94b2c3994a6c9a1beb 0 785 1595 1222 2015-11-06T10:06:27Z Oliver 1 wikitext text/x-wiki * [[Electronic Control Unit#RSM|Rain Sensor Module]] * [[Restraint System Monitoring]] d19d10d5d490ac3558e25e2551e508081db1ca29 0 925 1596 2015-11-06T10:06:45Z Oliver 1 Redirected page to [[Vehicle Crash Prediction]] wikitext text/x-wiki #REDIRECT [[Vehicle Crash Prediction]] 82e63a073fa6f2e261c455aab019d22ec7dbd7ed 0 926 1597 2015-11-06T10:07:04Z Oliver 1 Redirected page to [[Pedestrian Crash Prediction]] wikitext text/x-wiki #REDIRECT [[Pedestrian Crash Prediction]] 8521ff50a0827a488d55c5a5f6f42a1e4f37dfa3 0 927 1598 2015-11-06T10:07:47Z Oliver 1 Redirected page to [[Occupant Pre Conditioning]] wikitext text/x-wiki #REDIRECT [[Occupant Pre Conditioning]] c3493d71c38e4ffd599192aefdb8009e2d1ef57c 0 928 1599 2015-11-06T10:08:06Z Oliver 1 Redirected page to [[Restraint System Pre conditioning]] wikitext text/x-wiki #REDIRECT [[Restraint System Pre conditioning]] 10869fcbbf9f36d3a69c606ee7d59e7f605968a6 0 929 1600 2015-11-06T10:09:38Z Oliver 1 Redirected page to [[Pedestrian Protection system Pre conditioning]] wikitext text/x-wiki #REDIRECT [[Pedestrian Protection system Pre conditioning]] ee4c64c29fa8e1fa170f909622ad1b6c79ff5635 0 271 1601 314 2015-11-06T10:11:21Z Oliver 1 wikitext text/x-wiki The "Protocol Control Information” information is needed to pass a [[SDU]] from one [[instance]] of a specific protocol layer to another instance. E.g. it contains source and target information. The PCI is added by a [[protocol layer]] on the transmission side and is removed again on the receiving side. [[Category:AUTOSAR]] 664d41e60a25cc0173f8198032dfaa9456eb04dd 0 77 1602 315 2015-11-06T10:11:37Z Oliver 1 wikitext text/x-wiki * [[Protocol Control Information]] * [[Post Crash Information]] 62ea9f399e1c27b1148c2cb8cca8a8203513c6f3 0 930 1603 2015-11-06T10:12:06Z Oliver 1 Redirected page to [[Anti-Theft Warning System]] wikitext text/x-wiki #REDIRECT [[Anti-Theft Warning System]] 91505f02c4d2871100b9ac18191c669329ac5032 0 931 1604 2015-11-06T10:12:20Z Oliver 1 Redirected page to [[Battery Backed Sensor]] wikitext text/x-wiki #REDIRECT [[Battery Backed Sensor]] 38616aae9ccd6dea4cdf6248ba32b7fb73726dc7 0 159 1605 1500 2015-11-06T10:13:27Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ECM || || Engine Control Module |- |ESC, ESP || Electronic Stability Control || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |- |LSM || Light Switch Module || |- |RSM || Rain Sensor Module || |- |TBM || Trailer Brake Module || |- |TRM || Trailer Module || |- |AFS || Active Front Steering<br>Advanced Frontlighting System || |- |TCS || Traction Control System || |- |ACC || Adaptive Cruise Control || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. cc285521f07899d68370db832020bafe32f7d0bb 1606 1605 2015-11-06T10:14:09Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ECM || Engine Control Module || |- |ESC, ESP || Electronic Stability Control || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |- |LSM || Light Switch Module || |- |RSM || Rain Sensor Module || |- |TBM || Trailer Brake Module || |- |TRM || Trailer Module || |- |AFS || Active Front Steering<br>Advanced Frontlighting System || |- |TCS || Traction Control System || |- |ACC || Adaptive Cruise Control || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 6867a0bd458dbd3bdaff0b819225737ba587ebb7 1622 1606 2015-11-06T10:27:54Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |Abbr. || Full name || German full name |- |SBC || Sensoric Brake Control || Elektrohydraulisches Bremssystem |- |ABS || || Anti Blockiersystem |- |ECM || Engine Control Module || |- |ESC, ESP || Electronic Stability Control || Elektronisches Stabilitätsprogramm |- |BCM || Body Control Module<br>Brake Control Module || |- |IPC || Instrument Panel Cluster || |- |LSM || Light Switch Module || |- |RSM || Rain Sensor Module || |- |TBM || Trailer Brake Module || |- |TRM || Trailer Module || |- |AFS || Active Front Steering<br>Advanced Frontlighting System || |- |TCS || Traction Control System || |- |ACC || Adaptive Cruise Control || |- |PDC || Park Distance Control || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 35c01813f881004bd0e44d32dae9c2708bfd6568 0 932 1607 2015-11-06T10:14:18Z Oliver 1 Redirected page to [[Electronic Control Unit#ECM]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#ECM]] fde7116de525d9b2ed40acc1196ca73aaf85e3c5 0 933 1608 2015-11-06T10:14:56Z Oliver 1 Redirected page to [[Glass Brake Sensor]] wikitext text/x-wiki #REDIRECT [[Glass Brake Sensor]] 51eec87672c32f47ccf2c46051bb98a8a899acc9 0 934 1609 2015-11-06T10:15:27Z Oliver 1 Redirected page to [[Immobilizer]] wikitext text/x-wiki #REDIRECT [[Immobilizer]] ac590a83b4f0de44dcd296a14f3c65e668eb85fd 0 935 1610 2015-11-06T10:17:52Z Oliver 1 Redirected page to [[wikipedia:Electric vehicle]] wikitext text/x-wiki #REDIRECT [[wikipedia:Electric_vehicle|Electric vehicle]] 96694fc6429b46a423dc9ca46a4662f7f7f30f1a 0 936 1611 2015-11-06T10:18:04Z Oliver 1 Redirected page to [[Inclination sensor]] wikitext text/x-wiki #REDIRECT [[Inclination sensor]] 2b4c86000ae1419509fd8e27319e2d6dc5fbdeef 0 937 1612 2015-11-06T10:18:16Z Oliver 1 Redirected page to [[Interior Scanner]] wikitext text/x-wiki #REDIRECT [[Interior Scanner]] c6e0ba099746b4f5a7614bbd06e1ce927c491de4 0 938 1613 2015-11-06T10:18:35Z Oliver 1 Created page with "Left Hand Front Door" wikitext text/x-wiki Left Hand Front Door af6fbc306ab39bb5d8fdcee014723d4cb759de70 0 939 1614 2015-11-06T10:18:49Z Oliver 1 Created page with "Left Hand Rear Door" wikitext text/x-wiki Left Hand Rear Door 38dbdc444e977090102ec6270324cab8da5b6ba4 0 73 1615 76 2015-11-06T10:22:43Z Oliver 1 wikitext text/x-wiki [[wikipedia:Original_equipment_manufacturer|Original Equipment Manufacturer]], resp. vehicle manufacturer. 3541ed9061439d1eccda5d056376206402b5547f 0 940 1616 2015-11-06T10:23:57Z Oliver 1 Redirected page to [[Passive Entry]] wikitext text/x-wiki #REDIRECT [[Passive Entry]] c390343a444bae0c578938aa41b61dbf2cef22cf 0 941 1617 2015-11-06T10:25:05Z Oliver 1 Redirected page to [[Passive Alarm Theft Sensor]] wikitext text/x-wiki #REDIRECT [[Passive Alarm Theft Sensor]] 31d2c32f71e56cbe40223a305753f6c3309f2c45 0 942 1618 2015-11-06T10:25:24Z Oliver 1 Created page with "Right Hand Front Door" wikitext text/x-wiki Right Hand Front Door 8c79b84e83b24d146248f0360c7c966ab8dc5809 0 943 1619 2015-11-06T10:25:35Z Oliver 1 Created page with "Right Hand Rear Door" wikitext text/x-wiki Right Hand Rear Door e01f79e9118819de728ba4a56b562ebce0f76b59 0 944 1620 2015-11-06T10:25:52Z Oliver 1 Redirected page to [[Remote Keyless Entry]] wikitext text/x-wiki #REDIRECT [[Remote Keyless Entry]] a226e034bcb19fd4b0e88527c1e8ac74d7b14c92 0 945 1621 2015-11-06T10:26:43Z Oliver 1 Redirected page to [[Heating Ventilation and Air Conditioning]] wikitext text/x-wiki #REDIRECT [[Heating Ventilation and Air Conditioning]] 04b868c854a202ca225105398fff900133d8c2af 0 830 1623 1277 2015-11-06T10:28:29Z Oliver 1 Redirected page to [[Electronic Control Unit#PDC]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit#PDC|Park Distance Control]] 433d17b140443ccd9098dddc2d39a678fc800a7f 0 946 1624 2015-11-06T10:30:06Z Oliver 1 Redirected page to [[Brake Assist]] wikitext text/x-wiki #REDIRECT [[Brake Assist]] d938da3dc8127167b933d6136c728dbf8cb26aec 0 947 1625 2015-11-06T10:30:23Z Oliver 1 Redirected page to [[Basic Rear Wheel Steering]] wikitext text/x-wiki #REDIRECT [[Basic Rear Wheel Steering]] b7d34d26d2f1f8fedc64d6324fcd43737c09cd0c 0 948 1626 2015-11-06T10:30:42Z Oliver 1 Redirected page to [[Basic Steering Torque Superposition]] wikitext text/x-wiki #REDIRECT [[Basic Steering Torque Superposition]] b905bd27d43c65af869ca4a61f0e07b7ec9d837e 0 949 1627 2015-11-06T10:30:56Z Oliver 1 Redirected page to [[Basic Steering Angle Superposition]] wikitext text/x-wiki #REDIRECT [[Basic Steering Angle Superposition]] 55719bcf28f6ac706028b2f3a9ae07d7fcbe8c65 0 950 1628 2015-11-06T10:31:09Z Oliver 1 Redirected page to [[Cornering Brake Control]] wikitext text/x-wiki #REDIRECT [[Cornering Brake Control]] f4649ab9ebf3ee2325f5c0edb21df96424159a17 0 951 1629 2015-11-06T10:31:47Z Oliver 1 Redirected page to [[Centre of Gravity]] wikitext text/x-wiki #REDIRECT [[Centre of Gravity]] 128fea8ef9f20194531bab4ab55204230aafa0d6 0 952 1630 2015-11-06T10:32:02Z Oliver 1 Redirected page to [[Driver Assistance System]] wikitext text/x-wiki #REDIRECT [[Driver Assistance System]] f2a8390acea9605d90bf6073ce8455f24668d1f2 0 953 1631 2015-11-06T10:32:36Z Oliver 1 Redirected page to [[Hill Decent Control]] wikitext text/x-wiki #REDIRECT [[Hill Decent Control]] c5cc2722620558ee2f28fe35b7b406731d61c309 0 954 1632 2015-11-06T10:32:49Z Oliver 1 Redirected page to [[Hill Hold Control]] wikitext text/x-wiki #REDIRECT [[Hill Hold Control]] e56190f4ddddfda8ae9d3d2a3b112d6a3586cba4 0 955 1633 2015-11-06T10:33:08Z Oliver 1 Redirected page to [[Roll Stability Control]] wikitext text/x-wiki #REDIRECT [[Roll Stability Control]] 712cf8ddddd968596838bd653d10f2764a585d09 0 956 1634 2015-11-06T10:33:24Z Oliver 1 Redirected page to [[Stand Still Manager]] wikitext text/x-wiki #REDIRECT [[Stand Still Manager]] fee758db42eb5265d541d79b93a374e2dc3aefdc 0 957 1635 2015-11-06T10:33:53Z Oliver 1 Redirected page to [[Variable Gear Ratio]] wikitext text/x-wiki #REDIRECT [[Variable Gear Ratio]] 8afbe9176be3ad05e3fd062e6b9ddb4aed196f40 0 958 1636 2015-11-06T10:34:09Z Oliver 1 Redirected page to [[Vehicle Longitudinal Control]] wikitext text/x-wiki #REDIRECT [[Vehicle Longitudinal Control]] b118e2a8ddcb15f11914768af873855b64932d36 0 959 1637 2015-11-06T10:34:50Z Oliver 1 Redirected page to [[Yaw Rate Control]] wikitext text/x-wiki #REDIRECT [[Yaw Rate Control]] f156cd156e0c5ed3e9f1ba7017816b7785f410bf 0 960 1638 2015-11-06T10:36:43Z Oliver 1 Redirected page to [[wikipedia:Residual-current device]] wikitext text/x-wiki #REDIRECT [[wikipedia:Residual-current_device|residual-current device]] 9a60967e61792cae6eee1b0d47aaecec2bc607d3 0 79 1639 653 2015-11-06T10:37:31Z Oliver 1 wikitext text/x-wiki * [[Pulse Width Modulation]] * [[PWM Driver]] 0e5bce838363a69ee4f869ceb8df70e13fb2f76f 0 961 1640 2015-11-06T10:42:06Z Oliver 1 Created page with "In-Cable Control and Protection Device. Some relevant normative documents are * DIN IEC 62752 * IEC 61851 * ISO 15118" wikitext text/x-wiki In-Cable Control and Protection Device. Some relevant normative documents are * DIN IEC 62752 * IEC 61851 * ISO 15118 dc5329d93138f9f7b1bf0825d74a8633b8619b46 0 962 1641 2015-11-06T10:44:35Z Oliver 1 Redirected page to [[IC-CPD]] wikitext text/x-wiki #REDIRECT [[IC-CPD]] 616f30c664e716ffaafac9c1b3b34cd758b3ed24 0 963 1642 2015-11-06T12:14:46Z Oliver 1 Redirected page to [[Work Package]] wikitext text/x-wiki #REDIRECT [[Work Package]] 7bb93354801f9a1064de4e0d41a7aabff9bca319 0 19 1643 1080 2015-11-06T12:26:58Z Oliver 1 wikitext text/x-wiki * [[Analog Digital Converter]] * [[ADC Driver]] [[Category:hardware]] cdedd533781d53ed1f55d0ba540587dedc9e0b89 0 21 1644 1083 2015-11-06T12:27:54Z Oliver 1 Redirected page to [[Application Programming Interface]] wikitext text/x-wiki #REDIRECT [[Application Programming Interface]] 7f3308f665ea09cce11f74304e8f8d018712b863 0 964 1645 2015-11-06T12:27:58Z Oliver 1 Created page with "An Application Programming Interface (API) is the prescribed method of a specific software part by which a programmer writing a program can make requests to that software part..." wikitext text/x-wiki An Application Programming Interface (API) is the prescribed method of a specific software part by which a programmer writing a program can make requests to that software part. It precisely defines the interfaces with all it's parameters. [[Category:software]] d9c697b95e9f19ece0b520c0c94d25b95bc97c27 0 965 1646 2015-11-06T12:29:05Z Oliver 1 Created page with "Automotive [[Safety]] Integrity Levels (ASIL) are used within [[ISO 26262]] to express the level of risk reduction required to prevent a specific hazard, with ASIL D represent..." wikitext text/x-wiki Automotive [[Safety]] Integrity Levels (ASIL) are used within [[ISO 26262]] to express the level of risk reduction required to prevent a specific hazard, with ASIL D representing the highest and ASIL A the lowest. The ASIL is assigned to the according safety goal and inherited to the safety requirements derived from it. a2b3a32d1ad1eb9d8897e331339914fda1a91349 0 24 1647 357 2015-11-06T12:29:15Z Oliver 1 Redirected page to [[Automotive Safety Integrity Level]] wikitext text/x-wiki #REDIRECT [[Automotive Safety Integrity Level]] 11573bb4b731c095ea25b61acb70c811d7d5ddfd 0 966 1648 2015-11-06T12:29:47Z Oliver 1 Redirected page to [[Application Software]] wikitext text/x-wiki #REDIRECT [[Application Software]] [[Category:Software]] a6ffa3de16bbf11f020c8b6c9bbb114418ede3c2 0 967 1649 2015-11-06T12:30:35Z Oliver 1 Redirected page to [[Basic SoftWare Module Description]] wikitext text/x-wiki #REDIRECT [[Basic SoftWare Module Description]] 831e7996ba4246251224294b5fb65b617cb6945c 0 362 1650 426 2015-11-06T12:31:59Z Oliver 1 Redirected page to [[wikipedia:Cyclic redundancy check]] wikitext text/x-wiki #REDIRECT [[wikipedia:Cyclic_redundancy_check|Cyclic Redundancy Check]] ddb1b2b31b25598d14cfc633e5dc1b5cf5565222 0 968 1651 2015-11-06T12:32:47Z Oliver 1 Created page with "Conformance Test Agency<br /> This is an organization performing a [[role]] with specific tasks in the conformance test process. Two possibilities are distinguished, a third..." wikitext text/x-wiki Conformance Test Agency<br /> This is an organization performing a [[role]] with specific tasks in the conformance test process. Two possibilities are distinguished, a [[third party]] CTA or a [[first party]] CTA (which is also a product supplier). The tasks/services provided by a CTA is: - Provision of a [[CTS]] - Test execution - Attestation of product conformance For a third party CTA the focus is on the attestation and for a first party the focus is on the test execution. 408dbfc104eac47a138d2ea6ed0fdd5a925428c3 0 33 1652 499 2015-11-06T12:32:53Z Oliver 1 Redirected page to [[Conformance Test Agency]] wikitext text/x-wiki #REDIRECT [[Conformance Test Agency]] a4b3baf3602b09456bf9e06e952ca26cdaaee2f9 0 969 1653 2015-11-06T12:33:34Z Oliver 1 Created page with "Conformance Test Suite Is a test implementation used in the context of Conformance Testing. Typically, multiple test implementations from different vendors (e.g. [[CTA]]) will..." wikitext text/x-wiki Conformance Test Suite Is a test implementation used in the context of Conformance Testing. Typically, multiple test implementations from different vendors (e.g. [[CTA]]) will exist, each of which implements the standardized Conformance Test specifications. ISO 9646 distinguishes between Abstract Test Suites and Executable Test Suites. For AUTOSAR the earlier relates to the Conformance Test Specifications, whereas the latter to the test implementations or Conformance Test Suites. 73b6edc0a1c398865b60ae106ab6a82a073658d0 0 34 1654 157 2015-11-06T12:33:43Z Oliver 1 Redirected page to [[Conformance Test Suite]] wikitext text/x-wiki #REDIRECT [[Conformance Test Suite]] 7bc27bd6430d4fe119aa16a54944a9c4f8b822b1 0 36 1655 39 2015-11-06T12:34:44Z Oliver 1 Redirected page to [[wikipedia:Dynamic Host Configuration Protocol]] wikitext text/x-wiki #REDIRECT [[wikipedia:Dynamic_Host_Configuration_Protocol|Dynamic Host Configuration Protocol]] 14c47a6d6ce9e31bffb52061eaa26b100b182741 0 38 1656 41 2015-11-06T12:35:07Z Oliver 1 Redirected page to [[Data Length Code]] wikitext text/x-wiki #REDIRECT [[Data Length Code]] 6dc9358705cb3cd443346303aa4c9ba9030cd0d4 0 39 1657 42 2015-11-06T12:35:28Z Oliver 1 Redirected page to [[Diagnostics over Internet Protocol]] wikitext text/x-wiki #REDIRECT [[Diagnostics over Internet Protocol]] 62cbfaedbf4acf1fbfc1f0f9e6d149789a244b46 0 970 1658 2015-11-06T12:36:14Z Oliver 1 Created page with "Diagnostics over Internet Protocol is specified in [[ISO 13400]]." wikitext text/x-wiki Diagnostics over Internet Protocol is specified in [[ISO 13400]]. 42622c87ce5a2c27f91cc41c23c0a57f223ee2bb 0 43 1659 46 2015-11-06T12:37:36Z Oliver 1 Redirected page to [[wikipedia:Floating-point unit]] wikitext text/x-wiki #REDIRECT [[wikipedia:Floating-point_unit|Floating Point Unit]] ad5c25714044695ae13598bfe1ed1bc295d12c6a 0 366 1660 663 2015-11-06T12:38:43Z Oliver 1 Redirected page to [[General Purpose Timer]] wikitext text/x-wiki #REDIRECT [[General Purpose Timer]] 95c8b48afbb2dc5cf8ac7072a8bc691b4875643e 0 971 1661 2015-11-06T12:39:07Z Oliver 1 Created page with "General Purpose Timer see also [[GPT Driver]]" wikitext text/x-wiki General Purpose Timer see also [[GPT Driver]] 8f89c1ee1d39e5a74c6b5c028c6f9eddadaa9d44 0 45 1662 48 2015-11-06T12:40:14Z Oliver 1 Redirected page to [[wikipedia:GSM]] wikitext text/x-wiki #REDIRECT [[wikipedia:GSM|Global System for Mobile Communication]] b09455253bf0c46bfa401dcbe839c0d9dbd10222 0 229 1663 266 2015-11-06T12:41:56Z Oliver 1 Redirected page to [[Implementation Conformance Class]] wikitext text/x-wiki #REDIRECT [[Implementation Conformance Class]] c1badb71ad2f388fc37dbb253e6ae796a7142927 1665 1663 2015-11-06T12:42:49Z Oliver 1 Redirected page to [[Implementation Conformance Class#ICC1]] wikitext text/x-wiki #REDIRECT [[Implementation Conformance Class#ICC1]] d4b58c976f49e3d3b1a3a50eb5915a6277ace85a 0 972 1664 2015-11-06T12:42:21Z Oliver 1 Created page with "= ICC1 = An ICC1 cluster offers a [[software-component interface]] (SW-CI) and/ or an [[AUTOSAR network interface]] (NWI). The SW-CI and NWI of an ICC1 cluster provide the fun..." wikitext text/x-wiki = ICC1 = An ICC1 cluster offers a [[software-component interface]] (SW-CI) and/ or an [[AUTOSAR network interface]] (NWI). The SW-CI and NWI of an ICC1 cluster provide the functional behavior as specified in the AUTOSAR specifications on [[ICC3]] level. In an ICC1 cluster the basic software is regarded as a black box. It allows legacy platforms to migrate to AUTOSAR: - to be integrated into an AUTOSAR network - to support [[SW-C]]s. The features of an ICC1 cluster can be a subset of the ICC3 features (e.g. [[FlexRay]] not used). This has to be indicated in the [[Implementation Conformance Statement]] (ICS). The functionality represented in AUTOSAR by the [[RTE]] must be a part of any ICC1 cluster that provides an SW-CI. Typically an ICC1 cluster - is not structured into Basic Software ([[BSW]]) modules (ICC3) or BSW module clusters ([[ICC2]]) - has a proprietary internal structure and might consist of legacy/proprietary or highly optimized code. An ICC1 cluster shall provide an interface to the [[boot loader]]. ICC1 shall support SW-C compatible configuration for SW-CI and AUTOSAR Network compatible Configuration for NWI. 4696422ab1f06cb7295051518ec9040e822e69ba 1666 1664 2015-11-06T12:43:20Z Oliver 1 wikitext text/x-wiki = ICC1 = An ICC1 cluster offers a [[software-component interface]] (SW-CI) and/ or an [[AUTOSAR network interface]] (NWI). The SW-CI and NWI of an ICC1 cluster provide the functional behavior as specified in the AUTOSAR specifications on [[ICC3]] level. In an ICC1 cluster the basic software is regarded as a black box. It allows legacy platforms to migrate to AUTOSAR: - to be integrated into an AUTOSAR network - to support [[SW-C]]s. The features of an ICC1 cluster can be a subset of the ICC3 features (e.g. [[FlexRay]] not used). This has to be indicated in the [[Implementation Conformance Statement]] (ICS). The functionality represented in AUTOSAR by the [[RTE]] must be a part of any ICC1 cluster that provides an SW-CI. Typically an ICC1 cluster - is not structured into Basic Software ([[BSW]]) modules (ICC3) or BSW module clusters ([[ICC2]]) - has a proprietary internal structure and might consist of legacy/proprietary or highly optimized code. An ICC1 cluster shall provide an interface to the [[boot loader]]. ICC1 shall support SW-C compatible configuration for SW-CI and AUTOSAR Network compatible Configuration for NWI. = ICC2 = ICC2 clusters logically related [[ICC3]] Basic Software ([[BSW]]) modules (2… N modules). The number of Cluster Features in an ICC2 cluster is a subset of the union of the number of features of the clustered ICC3 modules. Each ICC2 cluster presents a subset of the clustered ICC3 module’s interfaces. ICC2 cluster provides the functional behavior as specified in the AUTOSAR specifications on ICC3 level. ICC2 cluster have a proprietary internal structure and might consist of proprietary or highly optimized code. ICC2 shall support AUTOSAR ECU Configuration description as an input for the Cluster Configuration It shall be possible to combine ICC2 Clusters and ICC3 Modules in a BSW Architecture. [[Application interface Conformance]] (above [[RTE]], [[software-component interface]], [[SW-CI]]) and [[Bus Conformance]] (AUTOSAR network interface, [[NWI]]) must be testable for a BSW which contain one or more ICC2 clusters. 50f891472d8aa191fbf337d80a1e4c2195f0f110 1668 1666 2015-11-06T12:44:10Z Oliver 1 wikitext text/x-wiki = ICC1 = An ICC1 cluster offers a [[software-component interface]] (SW-CI) and/ or an [[AUTOSAR network interface]] (NWI). The SW-CI and NWI of an ICC1 cluster provide the functional behavior as specified in the AUTOSAR specifications on [[ICC3]] level. In an ICC1 cluster the basic software is regarded as a black box. It allows legacy platforms to migrate to AUTOSAR: - to be integrated into an AUTOSAR network - to support [[SW-C]]s. The features of an ICC1 cluster can be a subset of the ICC3 features (e.g. [[FlexRay]] not used). This has to be indicated in the [[Implementation Conformance Statement]] (ICS). The functionality represented in AUTOSAR by the [[RTE]] must be a part of any ICC1 cluster that provides an SW-CI. Typically an ICC1 cluster - is not structured into Basic Software ([[BSW]]) modules (ICC3) or BSW module clusters ([[ICC2]]) - has a proprietary internal structure and might consist of legacy/proprietary or highly optimized code. An ICC1 cluster shall provide an interface to the [[boot loader]]. ICC1 shall support SW-C compatible configuration for SW-CI and AUTOSAR Network compatible Configuration for NWI. = ICC2 = ICC2 clusters logically related [[ICC3]] Basic Software ([[BSW]]) modules (2… N modules). The number of Cluster Features in an ICC2 cluster is a subset of the union of the number of features of the clustered ICC3 modules. Each ICC2 cluster presents a subset of the clustered ICC3 module’s interfaces. ICC2 cluster provides the functional behavior as specified in the AUTOSAR specifications on ICC3 level. ICC2 cluster have a proprietary internal structure and might consist of proprietary or highly optimized code. ICC2 shall support AUTOSAR ECU Configuration description as an input for the Cluster Configuration It shall be possible to combine ICC2 Clusters and ICC3 Modules in a BSW Architecture. [[Application interface Conformance]] (above [[RTE]], [[software-component interface]], [[SW-CI]]) and [[Bus Conformance]] (AUTOSAR network interface, [[NWI]]) must be testable for a BSW which contain one or more ICC2 clusters. = ICC3 = For ICC3 the AUTOSAR [[BSW]] consists of [[BSW modules]] as defined in the [[Basic Software Module List]], including the [[RTE]]. ICC3 is the highest level of granularity. All [[Basic Software module]]s as defined in the BSW module list including the RTE, must comply with the defined interfaces and functionality as specified in their respective [[Software specification document]] (SWS). [[Category:AUTOSAR]] 6f1264d62e5008d0dc9c029dbfe8c036cc06dccd 0 231 1667 268 2015-11-06T12:43:34Z Oliver 1 Redirected page to [[Implementation Conformance Class#ICC2]] wikitext text/x-wiki #REDIRECT [[Implementation Conformance Class#ICC2]] 2791a5e37d391de26a1e14b887c6903cc6a7c96a 0 233 1669 270 2015-11-06T12:44:50Z Oliver 1 Redirected page to [[Implementation Conformance Class#ICC3]] wikitext text/x-wiki #REDIRECT [[Implementation Conformance Class#ICC3]] 806b67436e14c2ec212a893549cab1e68a024199 0 49 1670 52 2015-11-06T12:45:10Z Oliver 1 Redirected page to [[Internet Control Message Protocol]] wikitext text/x-wiki #REDIRECT [[Internet Control Message Protocol]] 004d6bb39c04e1eec00a47bcca846a59f37bb90c 0 367 1671 652 2015-11-06T12:45:34Z Oliver 1 wikitext text/x-wiki * [[Input Capture Unit]] * [[ICU Driver]] 8f05ce598a0c911be714ed58f71281eafe262726 0 50 1672 53 2015-11-06T12:47:07Z Oliver 1 Redirected page to [[wikipedia:International Electrotechnical Commission]] wikitext text/x-wiki #REDIRECT [[wikipedia:International_Electrotechnical_Commission|International Electrotechnical Commission]] f8eead87ccdf455eb3dee9b41f4a8e2c985f72e7 0 53 1673 56 2015-11-06T13:05:53Z Oliver 1 Redirected page to [[Protocol Data Unit#L-PDU]] wikitext text/x-wiki #REDIRECT [[Protocol Data Unit#L-PDU]] 0e33c5ce77dac44afe4c3e3b5f7528d5eda0d6aa 0 227 1674 318 2015-11-06T13:06:07Z Oliver 1 wikitext text/x-wiki A Protocol Data Unit (PDU) contains [[SDU]] and [[PCI]]. On the transmission side the PDU is passed from the upper layer to the lower layer, which interprets this PDU as its SDU. = L-PDU = Protocol Data Unit ([[PDU]]) of the data link layer acecb09c30d5da353998f37706beb3f71eb66ec9 1675 1674 2015-11-06T13:06:46Z Oliver 1 wikitext text/x-wiki A Protocol Data Unit (PDU) contains [[SDU]] and [[PCI]]. On the transmission side the PDU is passed from the upper layer to the lower layer, which interprets this PDU as its SDU. = L-PDU = Protocol Data Unit of the [[Data Link Layer|data link layer]] eece19213177f0a6b169461332a15fcb270a9f4e 0 310 1676 364 2015-11-06T13:08:32Z Oliver 1 wikitext text/x-wiki A Service Data Unit (SDU) is the data passed by an upper layer, with the request to transmit the data. It is as well the data, which is extracted after reception by the lower layer and passed to the upper layer. An SDU is part of a [[PDU]]. = L-SDU = Service Data Unit of the [[Data Link Layer|data link layer]]. 9731f49422bbdacf0f1e22a50e6329c304f084f3 0 54 1677 57 2015-11-06T13:08:46Z Oliver 1 Redirected page to [[Service Data Unit#L-SDU]] wikitext text/x-wiki #REDIRECT [[Service Data Unit#L-SDU]] 06b8c9ab93bc79172bbe3b5bc2bab10963d55fc2 0 61 1678 64 2015-11-06T13:16:32Z Oliver 1 Redirected page to [[Memory Management Unit]] wikitext text/x-wiki #REDIRECT [[Memory Management Unit]] 06adaf1de9f372a7f185b4e92ef724cb449c8940 0 62 1679 65 2015-11-06T13:17:29Z Oliver 1 wikitext text/x-wiki Man Machine Interface<br /> see [[Human Machine Interface]] (HMI) fc6d91a166dc609793f020a80cf1ea524e0dc52a 0 64 1680 67 2015-11-06T13:18:16Z Oliver 1 Redirected page to [[wikipedia:MOST Bus]] wikitext text/x-wiki #REDIRECT [[wikipedia:MOST_Bus|Media Oriented Systems Transport]] afddc645ebf5e57ab7f2549d7058fa10a4270682 0 67 1681 70 2015-11-06T13:19:58Z Oliver 1 Redirected page to [[Protocol Data Unit#N-PDU]] wikitext text/x-wiki #REDIRECT [[Protocol Data Unit#N-PDU]] 71c4c8128798d2d5bd30f26b1ba53fce0594e011 0 227 1682 1675 2015-11-06T13:20:17Z Oliver 1 wikitext text/x-wiki A Protocol Data Unit (PDU) contains [[SDU]] and [[PCI]]. On the transmission side the PDU is passed from the upper layer to the lower layer, which interprets this PDU as its SDU. = L-PDU = Protocol Data Unit of the [[Data Link Layer|data link layer]]. = N-PDU = Protocol Data Unit of the [[Network Layer|network layer]] (transport protocols). [[Category:AUTOSAR]] [[Category:Software]] 23f3c5bc13e712c5acd6319d90a49545eb5636f7 0 310 1683 1676 2015-11-06T13:21:35Z Oliver 1 wikitext text/x-wiki A Service Data Unit (SDU) is the data passed by an upper layer, with the request to transmit the data. It is as well the data, which is extracted after reception by the lower layer and passed to the upper layer. An SDU is part of a [[PDU]]. = L-SDU = Service Data Unit of the [[Data Link Layer|data link layer]]. = N-SDU = Service Data Unit of the [[Network Layer|network layer]] (transport protocols). 0f93f50230f242a64548c82d7e998272099f0751 0 68 1684 71 2015-11-06T13:22:12Z Oliver 1 Redirected page to [[Service Data Unit#N-SDU]] wikitext text/x-wiki #REDIRECT [[Service Data Unit#N-SDU]] 36a20cab3883090d0977beaeb622b304ba58e242 0 74 1685 1060 2015-11-06T13:56:01Z Oliver 1 wikitext text/x-wiki * [[OSEK]] Implementation Language * [[Open Issue List]] dcf9dd3d1acbfad7a24e1b9f793d9b59a80f4993 0 75 1686 78 2015-11-06T13:56:25Z Oliver 1 Redirected page to [[wikipedia:OSEK]] wikitext text/x-wiki #REDIRECT [[wikipedia:OSEK|Open Systems and the Corresponding Interfaces for Automotive Electronics]] c5eb64260bf585ff8565f68e67e9014660a8b945 0 543 1687 1447 2015-11-06T14:03:56Z Oliver 1 wikitext text/x-wiki The PWM [[Driver]] (Pwm) is a [[Basic Software Module]] of the [[I/O Drivers]] for [[Pulse Width Modulation]]. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === === [[Standardized Interface]] === [[Category:AUTOSAR]] e5375f0b11d1875f54b060b3583ab9d73c629bfc 0 973 1688 2015-11-06T14:06:16Z Oliver 1 Created page with "A Change Request (CR) is also known as Request for Change (RfC)." wikitext text/x-wiki A Change Request (CR) is also known as Request for Change (RfC). 5023f5e5380bfa70e1e0aa83071e7372fc68b55b 0 80 1689 1264 2015-11-06T14:06:31Z Oliver 1 Redirected page to [[Change Request]] wikitext text/x-wiki #REDIRECT [[Change Request]] 4a7772831d0d75a578b88f47a59c52506c118462 0 374 1690 438 2015-11-06T14:07:18Z Oliver 1 Redirected page to [[Serial Peripheral Interface]] wikitext text/x-wiki #REDIRECT [[Serial Peripheral Interface]] 97c3050a2d7212e68bff49d1644f73dbd5173116 0 88 1691 91 2015-11-06T14:08:25Z Oliver 1 Redirected page to [[wikipedia:Transmission Control Protocol]] wikitext text/x-wiki #REDIRECT [[wikipedia:Transmission_Control_Protocol|Transmission Control Protocol]] 9833f50709b7602f961790be5cfea00317a1e7bf 0 89 1692 92 2015-11-06T14:08:35Z Oliver 1 Redirected page to [[Transport Protocol]] wikitext text/x-wiki #REDIRECT [[Transport Protocol]] 88ba4a970c5e4141df5e1f9c396a1c6b6a49f7da 0 90 1693 93 2015-11-06T14:09:23Z Oliver 1 Redirected page to [[Time Triggered Protocol]] wikitext text/x-wiki #REDIRECT [[Time Triggered Protocol]] a5d1454a6db1dd0210607c6275dc8a61ed72e034 0 93 1694 96 2015-11-06T14:10:44Z Oliver 1 Redirected page to [[wikipedia:USB]] wikitext text/x-wiki #REDIRECT [[wikipedia:USB|Universal Serial Bus]] 059d615824b710acbfba4c4d122a61a2d70c0607 0 95 1695 98 2015-11-06T14:11:08Z Oliver 1 Redirected page to [[Vehicle Mode Management]] wikitext text/x-wiki #REDIRECT [[Vehicle Mode Management]] 150e069e97cf4a9e783b8994a54baf6602d25bb8 0 101 1696 1093 2015-11-06T14:18:57Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Third party]] attestation to an organization conveying formal demonstration of its competence to carry out [[AUTOSAR conformance]] test tasks. Within the AUTOSAR environment two different scopes of accreditation exist: - In reference to ISO/IEC 17025 for accreditation of organizations performing conformance testing within own laboratories. - In reference to ISO/IEC Guide 65 for accreditation of [[Conformance Test Agency|Conformance Test Agencies]] (CTA) performing 3rd party product conformance attestation. f0388174bed9b6e834bf6646cbcf60e3e7071ef5 0 117 1697 1090 2015-11-06T14:20:47Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] This is a software tool which supports one or more [[task]]s defined as AUTOSAR tasks in the [[AUTOSAR methodology]]. Depending on the supported tasks, an [[AUTOSAR tool]] can act as an [[AUTOSAR authoring tool]], a [[AUTOSAR converter tool]], a [[AUTOSAR processor tool]] or as a combination of those. = Implementers = According to the AUTOSAR-paradigm "Common standard, concurring implementations", several software suppliers offer software implementations of the AUTOSAR standard. Some of the suppliers of AUTOSAR standard software are: {| class="wikitable sortable" |- ! Implementer !! BSW/MCAL Implementation !! BSW Configurator !! RTE Generator !! System Tooling !! License |- | [http://www.arccore.com/ ArcCore] || [http://www.arccore.com/products/arctic-core/ Arctic Core - Open source AUTOSAR] || [http://www.arccore.com/products/bsw-builder/ BSW Builder]|| [http://www.arccore.com/products/rte-builder/ RTE Builder] || [http://www.arccore.com/products/swc-builder/ SWC Builder] and [http://www.arccore.com/products/test-product-page/ Extract Builder] || GPL (Arctic Core and base version of Arctic Studio) / Commercial licenses available for all products |- | [https://www.comasso.org/ COMASSO_eV]|| [https://www.comasso.org/comasso_downloads BSW] || [https://www.comasso.org/comasso_downloads BSWDT] || No || No || Community |- | [http://www.conti-online.com/generator/www/de/en/continental/engineering_services/themes/autosar/autosar_overview_en.html Continental Engineering Services] || [http://www.conti-online.com/generator/www/de/en/continental/engineering_services/themes/autosar/autosar_software_en.html Yes] || [http://www.conti-online.com/generator/www/de/en/continental/engineering_services/themes/autosar/autosar_tooling_en.html Yes] || [http://www.conti-online.com/generator/www/de/en/continental/engineering_services/themes/autosar/autosar_tooling_en.html Yes] || [http://www.conti-online.com/generator/www/de/en/continental/engineering_services/themes/autosar/autosar_tooling_en.html Yes] || Commercial |- | [[wikipedia:DSPACE_GmbH|dSPACE]]|| No || No || [http://www.dspace.de/en/pub/home/products/sw/system_architecture_software/systemdesk/rte_generation_module_.cfm SystemDesk RTE Generator] || [http://www.dspace.de/en/pub/home/products/sw/system_architecture_software/systemdesk.cfm SystemDesk] || Commercial |- | [[wikipedia:Elektrobit]] || [http://automotive.elektrobit.com/ecu/autosar EB Tresos AutoCore] || [http://automotive.elektrobit.com/ecu/eb-tresos-studio EB Tresos Studio] || [http://automotive.elektrobit.com/ecu/eb-tresos-studio EB Tresos studio] || No || Commercial |- | [[wikipedia:ETAS Group|ETAS]] || [http://www.etas.com/en/applications_autosar_solutions.php Yes] || [http://www.etas.com/en/applications_autosar_solutions.php Yes] || [http://www.etas.com/en/products/rta_software_products.php RTA] || [http://www.etas.com/en/products/isolar_a.php ISOLAR-A] || Commercial |- | [http://www.freescale.com/ Freescale] || Yes <ref name="freescale1">http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=AUTOSAR_CS&tid=vanAutoSAR</ref> || No || Yes <ref name="freescale1"/> || Unknown || Commercial |- | [http://www.3ds.com/products/catia/portfolio/geensoft/geensoft-product-lines/autosar-builder/ Dassault Systèmes] || No|| [http://www.3ds.com/products/catia/portfolio/geensoft/geensoft-product-lines/autosar-builder/ GCE] || [http://www.3ds.com/products/catia/portfolio/geensoft/geensoft-product-lines/autosar-builder/ RTEG] || [http://www.3ds.com/products/catia/portfolio/geensoft/geensoft-product-lines/autosar-builder/ AAT] || Commercial |- | [http://www.hyundai-autron.com/ Hyundai-Autron] || Yes|| Yes || Yes || Yes || Commercial |- | [[wikipedia:KPIT Technologies Ltd.]] || [http://www.kpit.com/engineering/automotive/autosar-in-vehicle-networks#tab-1 K-SAR Suite] || [http://www.kpit.com/engineering/automotive/autosar-in-vehicle-networks#tab-3 K-SAR Editor] || [http://www.kpit.com/engineering/automotive/autosar-in-vehicle-networks#tab-3 Yes] || [http://www.kpit.com/engineering/automotive/autosar-in-vehicle-networks#tab-3 K-SAR Editor] || Commercial |- | [[wikipedia:Mecel]] || [http://www.mecel.se/products/mecel-picea Yes] || [http://www.mecel.se/products/mecel-picea Yes]|| [http://www.mecel.se/products/mecel-picea Yes]|| Unknown || Commercial. (Acquired by Mentor Graphics) <ref name="AcquireMecel">[http://www.microwavejournal.com/articles/21490], News link. Mentor Graphics acquires Mecel Picea AUTOSAR Development Suite.</ref> |- | [http://www.mentor.com/ Mentor Graphics]|| [http://www.mentor.com/products/vnd/autosar-products/volcano-vstar Volcano VSTAR] || [http://www.mentor.com/products/vnd/autosar-products/volcano-vstar Volcano VSTAR] || [http://www.mentor.com/products/vnd/autosar-products/volcano-vstar Volcano VSTAR]|| [http://www.mentor.com/products/vnd/autosar-products/volcano-system-architect/ Volcano Vehicle Systems Architect] || Commercial |- | [http://www.opensynergy.com/ OpenSynergy] || [http://www.opensynergy.com/Products/COQOS COQOS] (OS and BSW Scheduler only) || [http://www.opensynergy.com/Products/COQOS COQOS] || [http://www.opensynergy.com/Products/COQOS COQOS] || No || Commercial |- | [[wikipedia:Renesas Electronics]] || [http://www.renesas.eu/products/tools/middleware_and_drivers/c_autosar/mcal_pkg/mcal_pkg_tools_product_landing.jsp Yes] || No || No || No || Commercial |- | [[wikipedia:see4sys]] || [http://www.see4sys.com Yes] || [http://www.see4sys.com Yes]|| [http://www.see4sys.com Yes]|| [http://www.see4sys.com ECU-Designer] || Commercial |- | [[wikipedia:Vector Informatik|Vector Informatik GmbH]]|| [http://vector.com/vi_microsar_en.html MICROSAR] || [http://vector.com/vi_autosar_tools_en.html DaVinci Configurator Pro] || MICROSAR Rte Generator || [http://vector.com/vi_preevision_en.html PREEvision] / [http://vector.com/vi_davinci_developer_en.html DaVinci Developer] || Commercial |} [[Category:AUTOSAR]] c714835383b85b086d975952b854c8b008d0c4b3 0 974 1698 2015-11-06T14:45:56Z Oliver 1 Created page with " = ADAS = Advanced Driver Assistance System" wikitext text/x-wiki = ADAS = Advanced Driver Assistance System aee4ab353430fd1151570a3bddc2184f5d740b0e 0 879 1699 1351 2015-11-06T14:46:13Z Oliver 1 Redirected page to [[Driver Assistance System#ADAS]] wikitext text/x-wiki #REDIRECT [[Driver Assistance System#ADAS]] 8252d23688bb821d6bfea400745cb2688136f2f6 0 975 1700 2015-11-06T14:51:17Z Oliver 1 Created page with "= CSMA/CA = Carrier Sense Multiple Access / Collision Avoidance = CSMA/CD = Carrier Sense Multiple Access / Collision Detection" wikitext text/x-wiki = CSMA/CA = Carrier Sense Multiple Access / Collision Avoidance = CSMA/CD = Carrier Sense Multiple Access / Collision Detection 26ecf06e2ee81f0f6418300087c57a02fbdd86e4 1705 1700 2015-11-06T14:53:42Z Oliver 1 wikitext text/x-wiki = CSMA/CA = Carrier Sense Multiple Access / Collision Avoidance = CSMA/CD = Carrier Sense Multiple Access / Collision Detection [[Category:Hardware]] 71084007e25c7a66d1c8be671d9fd5253747a756 0 855 1701 1316 2015-11-06T14:51:28Z Oliver 1 Redirected page to [[Carrier Sense Multiple Access#CSMA/CA]] wikitext text/x-wiki #REDIRECT [[Carrier Sense Multiple Access#CSMA/CA]] 28afcc719f3529520815181d05d380fa7e2621bd 0 856 1702 1317 2015-11-06T14:51:41Z Oliver 1 Redirected page to [[Carrier Sense Multiple Access#CSMA/CD]] wikitext text/x-wiki #REDIRECT [[Carrier Sense Multiple Access#CSMA/CD]] 238880e0e6cf39a238a1960dde5d14731ac9fb18 0 854 1703 1314 2015-11-06T14:51:56Z Oliver 1 Redirected page to [[Carrier Sense Multiple Access]] wikitext text/x-wiki #REDIRECT [[Carrier Sense Multiple Access]] 4e908f1d00a332682f19f6453454179b955cb27a 0 126 1704 137 2015-11-06T14:53:18Z Oliver 1 wikitext text/x-wiki Functionality that is defined by an [[AUTOSAR module]] so that lower-level modules (i.e. lower in the Layered Software Architecture) can provide notification as required (e.g. when certain events occur or asynchronous processing completes). In AUTOSAR, modules usually provide a register mechanism for callback functions which is set through configuration. A module provides callbacks so that other modules can initiate its processing while the module calls [[callout]]s to execute functionality that could not be specified by AUTOSAR, i.e. [[integration code]]. [[Category:AUTOSAR]] [[Category:Software]] f512cfe4fd2edca7e0e3a78fe651d0745932bc50 0 132 1706 143 2015-11-06T14:54:14Z Oliver 1 wikitext text/x-wiki Software entity which uses services of a [[server]]. The client and the server might be located on one [[ECU]] or distributed on different calculation units (e.g. ECU, external [[diagnostic tester]]). [[Category:Software]] 243d87791b9a7d00eb8d917d27e85edd7401faa1 0 834 1707 1284 2015-11-06T14:54:34Z Oliver 1 wikitext text/x-wiki TODO [[Category:Software]] b526e9d1157f7d6878684487061c68314f0cc56d 0 136 1708 147 2015-11-06T14:54:53Z Oliver 1 wikitext text/x-wiki The Code Generator consumes complete and correctly formed [[XML]] for a [[BSW]] module and generates code and data that configures the [[module]]. [[Category:Software]] d771f6ece99cddf96ddd069033b241f1c5e6363b 0 976 1709 2015-11-06T14:58:00Z Oliver 1 Redirected page to [[wikipedia:FlexRay]] wikitext text/x-wiki #REDIRECT [[wikipedia:FlexRay|FlexRay]] 4472cc4dff3ec019a043cb2b2945d12bbc21b5cc 0 977 1710 2015-11-06T15:02:22Z Oliver 1 Created page with "AUTOSAR [[wikipedia:XML|Extensible Markup Language]] (XML) file according to the AUTOSAR XML Schema (xsd-file). [[Category:AUTOSAR]] [[Category:Software]]" wikitext text/x-wiki AUTOSAR [[wikipedia:XML|Extensible Markup Language]] (XML) file according to the AUTOSAR XML Schema (xsd-file). [[Category:AUTOSAR]] [[Category:Software]] 603e697a7a937c63b3df6fb84b01547435c1dd1d 0 426 1711 1129 2015-11-06T15:02:42Z Oliver 1 wikitext text/x-wiki The communication matrix is defining the [[message]]s/[[signal]] sent and received by each participating [[node]]. It could be defined in a [[FIBEX]]-file ([[FlexRay]]), CANdb-file ([[CAN]]) or AUTOSAR [[ARXML]]-file. [[Category:Software]] 8daae26de7cf03158fe2c1a6a812acc5db39c28f 0 144 1712 923 2015-11-06T15:03:43Z Oliver 1 /* Delegation Connector */ wikitext text/x-wiki A connector symbolizes the data flow from one [[PPort]] to one [[RPort]] of [[Software Component]]s (SW-C) or [[Composition Software Component|Software composition]]s. There are two types of connectors = Assembly Connector = Assembly connectors connect ports of [[Software Component]]s (SW-C). During the design of an [[AUTOSAR system]], ports between Software Components that need to communicate with each other are hooked up using Assembly Connectors. Such an Assembly Connector connects one SW-C with another SW-C. = Delegation Connector = Delegation connectors connect the [[port]]s of a [[Composition Software Component]] with the ports of its inner [[Software Component]]s. 06558577c90b363c546e814a7a5fbc17e23f179c 0 777 1713 1211 2015-11-06T15:44:53Z Oliver 1 wikitext text/x-wiki Halogen bulb with single filament (55W, 1500lm). [[Category:Hardware]] 6f83ce916867abc977cdaab38869271c164b6700 0 10 1714 1097 2015-11-06T20:35:27Z Oliver 1 Redirected page to [[NVRAM Block#Administrative Block]] wikitext text/x-wiki #REDIRECT [[NVRAM Block#Administrative Block]] c39da32d81d3f8b93d6b160aec42790292b1e040 0 2 1715 1438 2015-11-06T20:35:31Z Oliver 1 wikitext text/x-wiki The “NVRAM Block” is the entire structure, which is needed to administrate and to store a block of [[NV data]]. =Administrative Block= The “Administrative Block” is a Basic Storage Object that resides in RAM. It is a mandatory part of a NVRAM Block. [[Category:AUTOSAR]] 9ba75f00280f3b5b1e79ceda8833e34b0db31ea4 0 587 1716 1098 2015-11-06T20:36:31Z Oliver 1 wikitext text/x-wiki Unlearning/deleting of a no longer failed event/[[DTC]] after a defined number of [[operation cycle]]s from [[event memory]]. The [[Dem]] module provides the ability to remove a specific event from the event memory, if its fault conditions are not fulfilled for a certain period of time (operation cycles). This process is called as “aging” or “unlearning”. [[Category:Diagnostic]] 3aefed4222ba2268f87fcb8ba683571ebb3522fe 0 104 1717 1101 2015-11-06T20:44:03Z Oliver 1 Redirected page to [[ApplicationSwComponentType]] wikitext text/x-wiki #REDIRECT [[ApplicationSwComponentType]] 525e8b1a44fa88cbd34e9f6f6065d7475ec85547 0 978 1718 2015-11-06T20:44:12Z Oliver 1 Created page with "The Application Software Component (ApplicationSwComponentType) is an [[AtomicSwComponentType]] that is hardware independent. <br /> It implements (a part of) the software ..." wikitext text/x-wiki The Application Software Component (ApplicationSwComponentType) is an [[AtomicSwComponentType]] that is hardware independent. <br /> It implements (a part of) the software [[Application|application]] and can use all AUTOSAR communication mechanisms and services. In order to interact with sensors or actuators, it communicates via [[SensorActuatorSwComponentType|Sensor-Actuator Software Components]]. [[Category:AUTOSAR]] [[Category:Software]] 243d542c998b6c0360183a5050ffce371a538121 0 979 1719 2015-11-06T20:48:23Z Oliver 1 Created page with "An Atomic Software Component (AtomicSwComponentType) cannot be split into further [[Software Component|Software Components]] (as opposed to a CompositionSwComponentType|Soft..." wikitext text/x-wiki An Atomic Software Component (AtomicSwComponentType) cannot be split into further [[Software Component|Software Components]] (as opposed to a [[CompositionSwComponentType|Software Composition]]). An AtomicSwComponentType is a specific form of a [[SwComponentType|SwComponentType]] consisting of the same attributes plus one optional [[SwcInternalBehavior]] and one optional [[SymbolProps|Symbols Properties]]. The term AtomicSwComponentType can be used as a collective term for the following components, as they are specialized AtomicSwComponentTypes: * [[ApplicationSwComponentType]] * [[ServiceSwComponentType]] * [[SensorActuatorSwComponentType]] * [[EcuAbstractionSwComponentType]] * [[ComplexDeviceDriverSwComponentType]] * [[ServiceProxySwComponentType]] * [[NvBlockSwComponentType]] [[Category:AUTOSAR]] [[Category:Software]] 80b507f4882b02f3b121330a41ff04fa5828bbe6 0 980 1720 2015-11-06T20:51:00Z Oliver 1 Created page with "The Symbol Property (SymbolProps) provides the ability to attach a symbolic name to the [[shortName]] of a [[Software Component]] in order to avoid naming inconsistencies on [..." wikitext text/x-wiki The Symbol Property (SymbolProps) provides the ability to attach a symbolic name to the [[shortName]] of a [[Software Component]] in order to avoid naming inconsistencies on [[RTE]] source code level. This is especially useful if components from different suppliers are using the same names by coincidence. That way the SwComponentType.shortName can be overridden by the SymbolProps.symbol attribute. The resulting name related to an [[AtomicSwComponentType]] is called the “component type symbol”. This name is not applied for file names and it must be in line with C language requirements. SymbolProps are also used for [[ImplementationDatatype|ImplementationDatatypes]]. [[Category:AUTOSAR]] [[Category:Software]] eb323491d09047cbcfc138cfc253857d6dbbc15a 0 981 1721 2015-11-06T20:52:41Z Oliver 1 Created page with "A Service Software Component (ServiceSwComponentType) provides [[AUTOSAR Service|AUTOSAR Services]] to the [[Application Layer]] through Standardized AUTOSAR Interface|Stand..." wikitext text/x-wiki A Service Software Component (ServiceSwComponentType) provides [[AUTOSAR Service|AUTOSAR Services]] to the [[Application Layer]] through [[Standardized AUTOSAR Interface|Standardized AUTOSAR Interfaces]]. It may interact directly with [[Basic Software Module|Basic Software Modules]]. [[Category:AUTOSAR]] [[Category:Software]] 6b12b2cef57ab295128ae200f97e4e1417ed6614 0 387 1722 1469 2015-11-06T20:54:13Z Oliver 1 Redirected page to [[SensorActuatorSwComponentType]] wikitext text/x-wiki #REDIRECT [[SensorActuatorSwComponentType]] b2381d0544bc7d3d11ee19460ae377a2835e7ef0 0 392 1723 1466 2015-11-06T20:55:04Z Oliver 1 Redirected page to [[ServiceSwComponentType]] wikitext text/x-wiki #REDIRECT [[ServiceSwComponentType]] 038bd510acbf7881cb8dbe9cec33c55a6d908e1c 0 982 1724 2015-11-06T21:00:25Z Oliver 1 Created page with "The Sensor-Actuator Software Component (SensorActuatorSwComponentType) is a special type of an [[AtomicSwComponentType]] as it depends on specific hardware and is therefore no..." wikitext text/x-wiki The Sensor-Actuator Software Component (SensorActuatorSwComponentType) is a special type of an [[AtomicSwComponentType]] as it depends on specific hardware and is therefore not relocatable over different [[ECU|ECUs]] (as the used hardware is only available on a specific ECU). This is mostly relevant on the [[VFB]]-level where the Software Components are not (yet) assigned to any specific ECU and might be relocated on another ECU for some reason. A SensorActuatorSwComponentType * is usually written for a specific [[sensor]] or [[actuator]] and is therefore (usually) located on the same ECU as the sensor/actuator, * reads the [[AUTOSAR Signal]] that represents the electrical value from the [[IO Hardware Abstraction Layer]] via [[EcuAbstractionSwComponentType]] and transforms it into an AUTOSAR Signal representation of the physical value, * provides the AUTOSAR Signal representation the physical value of a sensor or actuator available for [[ApplicationSwComponentType|Application Software Components]]. Although it is very hardware specific, the Sensor-Actuator Software Component is located “above” the RTE and provides the “link” between the Application Software Component and the [[ECU Abstraction Layer]] via [[AUTOSAR Interface|AUTOSAR Interfaces]].<br /> A Sensor Software Component usually has a [[Client Port]] with [[ClientServerOperation]] OP_GET in order to retrieve the sensor data from the [[EcuAbstractionSwComponentType]]. On the other hand an Actuator Software Component uses a [[Client Port]] with ClientServerOperation OP_SET in order to provide new data to the actuator output. This is the “standard interface” between a SensorActuatorSwComponentType and an EcuAbstractionSwComponentType but other Interfaces are possible.<br /> Note that although a Sensor-Actuator Software Component accesses [[Port|Ports]] of the ECU Abstraction Software Component “below” the RTE, these Interfaces are no [[Standardized AUTOSAR Interface|Standardized AUTOSAR Interfaces]] and therefore the attribute [[isService]] of the Interface is not set to TRUE.<br /> The SensorActuatorSwComponentType requires a reference to the corresponding [[sensorActuator]] which in turn contains a reference to the [[HwType]] described in the [[ECU Resource Description]]. The EcuAbstractionSwComponentType or the [[Complex Device Driver]] on the other side also references the hardwareElement(s). [[Category:AUTOSAR]] [[Category:Software]] ebde5c39d2e5e5ed18d1f4b75a85ed7a9c0f5e50 0 983 1725 2015-11-06T21:15:11Z Oliver 1 Redirected page to [[EcuAbstractionSwComponentType]] wikitext text/x-wiki #REDIRECT [[EcuAbstractionSwComponentType]] 4f9e7f944a3465b970549e632a1cd9c269a90b13 1728 1725 2015-11-06T21:18:15Z Oliver 1 wikitext text/x-wiki The I/O Hardware Abstraction is a part of the [[ECU Abstraction]] and consists of one or more [[EcuAbstractionSwComponentType|ECU Abstraction Software Component(s)]]. [[Category:AUTOSAR]] [[Category:Software]] ddaa63d16ae2dcea0f7714d52a9efe6675fe1072 0 545 1726 1380 2015-11-06T21:15:36Z Oliver 1 Redirected page to [[EcuAbstractionSwComponentType]] wikitext text/x-wiki #REDIRECT [[EcuAbstractionSwComponentType]] 4f9e7f944a3465b970549e632a1cd9c269a90b13 1727 1726 2015-11-06T21:16:46Z Oliver 1 Undo revision 1726 by [[Special:Contributions/Oliver|Oliver]] ([[User talk:Oliver|talk]]) wikitext text/x-wiki [[Category:AUTOSAR]] The IO HW Abstraction (IoHwAb) is a [[Basic Software Module]] of the [[I/O HW Abstraction]] layer. It abstracts from the location of peripheral I/O devices (on-chip or on-board) and the [[ECU]] hardware layout (e.g. [[uC]] pin connections and signal level inversions). The I/O Hardware Abstraction does not abstract from the sensors/actuators! The different I/O devices might be accessed via [[I/O Drivers]]. === [[AUTOSAR Interface]] === Project (resp. hardware) specific. === [[Standardized AUTOSAR Interface]] === none === [[Standardized Interface]] === none fe607c3cca45fb55c3713ca0f5d4768dbf37f5f7 1729 1727 2015-11-06T21:18:24Z Oliver 1 Redirected page to [[I/O Hardware Abstraction]] wikitext text/x-wiki #REDIRECT [[I/O Hardware Abstraction]] 98f7d5aa0d93a26d7dd2e89ea2c505bfefd5b83e 0 984 1730 2015-11-06T21:21:58Z Oliver 1 Created page with "An ECU Abstraction Software Component (EcuAbstractionSwComponentType) is part of the [[Basic Software]], specifically the [[ECU Abstraction Layer]] and can therefore interact..." wikitext text/x-wiki An ECU Abstraction Software Component (EcuAbstractionSwComponentType) is part of the [[Basic Software]], specifically the [[ECU Abstraction Layer]] and can therefore interact with other Basic Software Modules via [[Standardized Interface|Standardized Interfaces]]. It contains reference(s) to the corresponding [[hardwareElement|hardwareElements]] and provides access to the [[ECU]]’s specific IO capabilities via [[Port|Ports]] to the [[SensorActuatorSwComponentType|Sensor-Actuator Software Component]]. [[Category:AUTOSAR]] [[Category:Software]] 09191805d2e4e3de9e704642665ad124ce7d182e 0 985 1731 2015-11-06T21:22:24Z Oliver 1 Redirected page to [[EcuAbstractionSwComponentType]] wikitext text/x-wiki #REDIRECT [[EcuAbstractionSwComponentType]] 4f9e7f944a3465b970549e632a1cd9c269a90b13 0 395 1732 776 2015-11-06T21:26:38Z Oliver 1 Redirected page to [[ComplexDeviceDriverSwComponentType]] wikitext text/x-wiki #REDIRECT [[ComplexDeviceDriverSwComponentType]] 5e0da394abf19d858e932832c95238667efdb3a3 0 449 1733 1353 2015-11-06T21:28:44Z Oliver 1 wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Basic Software Module#Complex Drivers|Complex Device Drivers]] = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[Memory Abstraction Interface]] (MemIf) * [[Flash EEPROM Emulation]] (Fee) * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) [[Category:AUTOSAR]] [[Category:Software]] 6e05fa945891471fe9f6a3e38f3bd4441129374b 1756 1733 2015-11-06T22:37:04Z Oliver 1 wikitext text/x-wiki for BSW Mode Manager see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Complex Device Driver|Complex Device Drivers]] = Services Layer = The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ==== Communication Services ==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ==== Memory Services ==== * [[NVRAM Manager]] (NvM) ==== System Services ==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ==== Diagnostic Services ==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) = ECU Abstraction Layer = The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ==== Communication HW Abstraction ==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ==== Memory HW Abstraction ==== * [[Memory Abstraction Interface]] (MemIf) * [[Flash EEPROM Emulation]] (Fee) * [[EEPROM Abstraction]] (Ea) ==== Onboard Device Abstraction ==== * [[Watchdog Interface]] (WdgIf) ==== I/O HW Abstraction ==== * [[IO HW Abstraction]] = Microcontroller Abstraction Layer = The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ==== Communication Drivers ==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ==== I/O Drivers ==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ==== Memory Drivers ==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ==== Microcontroller Drivers ==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) [[Category:AUTOSAR]] [[Category:Software]] a80e22aef84f3da748a94f547f0e4f7faec8674f 0 30 1734 775 2015-11-06T21:29:00Z Oliver 1 Redirected page to [[ComplexDeviceDriverSwComponentType]] wikitext text/x-wiki #REDIRECT [[ComplexDeviceDriverSwComponentType]] 5e0da394abf19d858e932832c95238667efdb3a3 0 986 1735 2015-11-06T21:29:18Z Oliver 1 Created page with "The Complex Device Driver (CDD) Software Component is used to model a function outside of the normal [[AUTOSAR Basic Software]] stack for complex or resource critical sensor..." wikitext text/x-wiki The Complex Device Driver (CDD) Software Component is used to model a function outside of the normal [[AUTOSAR Basic Software]] stack for complex or resource critical [[sensor]] evaluation or [[actuator]] control, especially for hardware that is not directly supported by AUTOSAR (like project specific [[ASIC]]s). The ComplexDeviceDriverSwComponentType can define [[Port|Ports]] to directly interact with [[Software Component|Software Components]] via [[AUTOSAR Interface|AUTOSAR Interfaces]] and it can also interact directly with Basic Software Modules via [[Standardized Interface|Standardized Interfaces]]. It needs to be mapped with the corresponding [[BswModuleDescription]] via [[SwcBswMapping]]. [[Category:AUTOSAR]] [[Category:Software]] 5bd3dd640f3b6b10178293fa9f9eab69f0439b99 0 390 1736 1467 2015-11-06T21:29:55Z Oliver 1 Redirected page to [[ServiceProxySwComponentType]] wikitext text/x-wiki #REDIRECT [[ServiceProxySwComponentType]] c8f78e883f9f7f50f0b5db32720054b4231fab2a 0 987 1737 2015-11-06T21:31:09Z Oliver 1 Created page with "The Service Proxy Software Component (ServiceProxySwComponentType) is a component that acts as a proxy to provide access to Internal Services for one or more remote [[ECU]]s...." wikitext text/x-wiki The Service Proxy Software Component (ServiceProxySwComponentType) is a component that acts as a proxy to provide access to Internal Services for one or more remote [[ECU]]s. The main use case for a ServiceProxySwComponentType is the distribution of the vehicle mode throughout the system (and to every ECU) where the [[Mode Manager]] is part of the [[Basic Software]]. A ServiceProxySwComponentType is similar to an [[ApplicationSwComponentType]], the difference being, however, that the same ServiceProxySwComponentType is instantiated during the system design into several ECUs. As a consequence, a connection between an [[Application Software Component]] and a Service Proxy Software Component that is shown as 1:1 connection in the [[VFB]] will be a 1:n connection in the system. This allows for the distribution of one request to several ECUs. [[Category:AUTOSAR]] [[Category:Software]] 5bb839a0c233320fa66323a71ee6f00e53cad962 0 988 1738 2015-11-06T21:37:38Z Oliver 1 Created page with "In case an [[ApplicationSwComponentType|Application Software Component]] needs to access nonvolatile data, there are two possible options: * The SwcInternalBehavior defines Nv..." wikitext text/x-wiki In case an [[ApplicationSwComponentType|Application Software Component]] needs to access nonvolatile data, there are two possible options: * The SwcInternalBehavior defines NvM Service Dependencies ([[NvBlockNeeds]]) * The Application Software Component communicates with an NVBlock Software Component The second option with an NVBlock Software Component (NvBlockSwComponentType) provides two main advantages: * it allows the modeling of the NV data at the [[VFB]] level, where the [[SwcInternalBehavior]] is not known, * it can be used to reduce the number of [[NvBlock|NvBlocks]] * one block can be used to store different small data elements * the same data elements can be used by different [[SwComponentPrototype|SwComponentPrototypes]] The NvBlockSwComponentType maps individual nonvolatile data elements to NvBlocks and interacts with the [[NVRAM Manager]] (NvM). It does not have any [[SwcInternalBehavior]] as the code is automatically generated by the [[RTE Generator]] based on the configured [[Nonvolatile Data Port|Nonvolatile Data Ports]]. An NvBlockSwComponentType can also have Ports with [[ClientServerInterfaces]] that are compatible with the [[Standardized AUTOSAR Interface|Standardized AUTOSAR Interfaces]] of the NVRAM Manager: * [[NvMService]] to send commands to the NVM. ** EraseBlock ** GetDataIndex ** GetErrorStatus ** InvalidateNvBlock ** ReadBlock ** RestoreBlockDefaults ** SetDataIndex ** SetRamBlockStatus ** WriteBlock * [[NvMNotifyJobFinished]] to notify the end of job. ** JobFinished * [[NvMNotifyInitBlock]] to request the application SW C to provide the default values in the RAM mirror. ** InitBlock * [[NvMAdmin]] to invoke some administrative operations to the NVM. ** SetBlockProtection a082fa3c197c2d134d8d0c9580f1f4fb6c148c3d 1740 1738 2015-11-06T21:38:09Z Oliver 1 wikitext text/x-wiki In case an [[ApplicationSwComponentType|Application Software Component]] needs to access nonvolatile data, there are two possible options: * The SwcInternalBehavior defines NvM Service Dependencies ([[NvBlockNeeds]]) * The Application Software Component communicates with an NVBlock Software Component The second option with an NVBlock Software Component (NvBlockSwComponentType) provides two main advantages: * it allows the modeling of the NV data at the [[VFB]] level, where the [[SwcInternalBehavior]] is not known, * it can be used to reduce the number of [[NvBlock|NvBlocks]] * one block can be used to store different small data elements * the same data elements can be used by different [[SwComponentPrototype|SwComponentPrototypes]] The NvBlockSwComponentType maps individual nonvolatile data elements to NvBlocks and interacts with the [[NVRAM Manager]] (NvM). It does not have any [[SwcInternalBehavior]] as the code is automatically generated by the [[RTE Generator]] based on the configured [[Nonvolatile Data Port|Nonvolatile Data Ports]]. An NvBlockSwComponentType can also have Ports with [[ClientServerInterfaces]] that are compatible with the [[Standardized AUTOSAR Interface|Standardized AUTOSAR Interfaces]] of the NVRAM Manager: * [[NvMService]] to send commands to the NVM. ** EraseBlock ** GetDataIndex ** GetErrorStatus ** InvalidateNvBlock ** ReadBlock ** RestoreBlockDefaults ** SetDataIndex ** SetRamBlockStatus ** WriteBlock * [[NvMNotifyJobFinished]] to notify the end of job. ** JobFinished * [[NvMNotifyInitBlock]] to request the application SW C to provide the default values in the RAM mirror. ** InitBlock * [[NvMAdmin]] to invoke some administrative operations to the NVM. ** SetBlockProtection [[Category:AUTOSAR]] [[Category:Software]] b615ecf6dd6fed346046922bce57b5c0633e595d 0 989 1739 2015-11-06T21:37:59Z Oliver 1 Redirected page to [[NvBlockSwComponentType]] wikitext text/x-wiki #REDIRECT [[NvBlockSwComponentType]] 19bc52055a278288eac8b80e0eb0ef753e23f297 0 388 1741 1448 2015-11-06T21:39:32Z Oliver 1 Redirected page to [[ParameterSwComponentType]] wikitext text/x-wiki #REDIRECT [[ParameterSwComponentType]] df78584ba7da46e81f78be393d5d62ecc20a9e6d 0 990 1742 2015-11-06T21:40:03Z Oliver 1 Redirected page to [[ParameterSwComponentType]] wikitext text/x-wiki #REDIRECT [[ParameterSwComponentType]] df78584ba7da46e81f78be393d5d62ecc20a9e6d 0 991 1743 2015-11-06T21:42:06Z Oliver 1 Created page with "The Parameter Software Component (ParameterSwComponentType – previously also called Calibration Parameter Software Component) is a [[SwComponentType]] that provides paramete..." wikitext text/x-wiki The Parameter Software Component (ParameterSwComponentType – previously also called Calibration Parameter Software Component) is a [[SwComponentType]] that provides parameter values which can be fixed data, const or variable. In contrast to an [[AtomicSwComponentType]] it cannot have a [[SwcInternalBehavior]] and does not support [[Port#Require Port|Require-Ports]] (RPorts). A ParameterSwComponentType is a simple container that provides (calibration) parameters to Software Components via [[Parameter Port|Parameter Ports]]. [[Category:AUTOSAR]] [[Category:Software]] c52eb1403fc12fcf9b497205cdc8346a5c2516a8 0 992 1744 2015-11-06T21:43:10Z Oliver 1 Redirected page to [[CompositionSwComponentType]] wikitext text/x-wiki #REDIRECT [[CompositionSwComponentType]] a98ff08c7170076c15c3ae91b5df0366c37d3cc3 0 389 1745 1360 2015-11-06T21:43:26Z Oliver 1 Redirected page to [[CompositionSwComponentType]] wikitext text/x-wiki #REDIRECT [[CompositionSwComponentType]] a98ff08c7170076c15c3ae91b5df0366c37d3cc3 0 993 1746 2015-11-06T21:46:28Z Oliver 1 Redirected page to [[CompositionSwComponentType]] wikitext text/x-wiki #REDIRECT [[CompositionSwComponentType]] a98ff08c7170076c15c3ae91b5df0366c37d3cc3 0 994 1747 2015-11-06T21:46:58Z Oliver 1 Redirected page to [[CompositionSwComponentType]] wikitext text/x-wiki #REDIRECT [[CompositionSwComponentType]] a98ff08c7170076c15c3ae91b5df0366c37d3cc3 0 995 1748 2015-11-06T21:47:05Z Oliver 1 Created page with "A Software Composition (or Composition Software Component, CompositionSwComponentType) allows encapsulation of functionality by aggregating existing Software Component Proto..." wikitext text/x-wiki A Software Composition (or Composition Software Component, CompositionSwComponentType) allows encapsulation of functionality by aggregating existing [[Software Component Prototype|Software Component Prototypes]] or other Software Compositions. Through [[Delegation Connector|Delegation Connectors]], a Composition Software Component explicitly specifies which [[Port|Ports]] of the internal components can communicate externally. A CompositionSwComponentType cannot have [[Service Port|Service Ports]] (Ports marked with [[isService]] flag set to TRUE). Software Compositions exist only on the modeling level and do not add any functionality as they do not have an [[SwcInternalBehavior|Internal Behavior]]. Nor do they affect the communication on the [[VFB]] or cause any (additional) code. During the integration process, the Software Compositions are “split up” (or “flattened”) so that only [[AtomicSwComponentType]](s) are visible. Therefore the Software Components of a Software Composition are not necessarily distributed on one and the same [[ECU]]. The [[Application software|application software]] of an entire vehicle eventually is represented by one Software Composition, the Top-level Composition. Furthermore, one Root Software Composition usually exists per ECU. [[Category:AUTOSAR]] [[Category:Software]] e389ff70fcc7a2b551aa6ff47f6f0de1d413e3a9 0 996 1749 2015-11-06T22:09:13Z Oliver 1 Created page with "Automotive suppliers are called Tier with the corresponding number according to their position in supplier chain. The supplier chain therefore looks like: Vehicle manufacture..." wikitext text/x-wiki Automotive suppliers are called Tier with the corresponding number according to their position in supplier chain. The supplier chain therefore looks like: Vehicle manufacturer ([[OEM]]) <= Tier1 <= Tier2 <= etc. = Module Supplier (Modul-Lieferant) = Provide functional units that are locally grouped. = System Supplier (Systemlieferant) = Provide functional units like power-train, steering, etc. = Component Supplier (Komponentenliferant) == Provide complex parts like connectors, [[ECU]]s, etc. = Part Supplier (Teilelieferant) = Provide simple parts, like screws. (Supplier definition according "Automobilzulieferer in Bewegung: Strategische Herausforderungen für mittelständische Unternehmen in einem turbulenten Umfeld" ISBN 978-3848721177) 2dae900bbffca0123583614c3fe9d4896f3b3fd1 0 611 1750 892 2015-11-06T22:09:49Z Oliver 1 Redirected page to [[Automotive supplier]] wikitext text/x-wiki #REDIRECT [[Automotive supplier]] d053700d4194a438059fdda617b48ff2a4c5cd17 0 977 1751 1710 2015-11-06T22:11:25Z Oliver 1 Redirected page to [[AUTOSAR XML Schema]] wikitext text/x-wiki #REDIRECT [[AUTOSAR XML Schema]] 87c45f05d6f55a9d60aa6611d9f4a924a37917cc 0 450 1752 1100 2015-11-06T22:31:46Z Oliver 1 wikitext text/x-wiki The Application Layer is the part where the project specific features are implemented by [[Software Component|Software Components]]. These Software Components communicate with each other and the [[Basic Software]] via the [[RTE]] and are independent of the actual hardware or any communication bus [[Category:AUTOSAR]] [[Category:Software]] 8747adaf10530e58bb19c1b4b8a64069c86f59c3 0 419 1753 1471 2015-11-06T22:32:55Z Oliver 1 wikitext text/x-wiki On the [[VFB]] level, a [[Software Component]] is modeled by its Software Component Description (SWCD), which is exchanged in [[ARXML]] format and contains the following from the Software Component point-of-view: * Operations and data elements provided and required * Requirements regarding the infrastructure * Resources needed (memory, CPU-time, etc.) * Information regarding the specific implementation [[Category:AUTOSAR]] [[Category:Software]] a34e58bd7696b2e6db0106b2999b73fdddf62b6c 0 414 1754 1456 2015-11-06T22:34:34Z Oliver 1 wikitext text/x-wiki The Runtime Environment (RTE) realizes the communication between [[Software Component|Software Components]] and the [[Basic Software]]. Software Components communicate with other components and/or [[Basic Software Module|Basic Software Modules]] exclusively via the RTE, which allows Software Components to be independent of any specific [[ECU]] and other Software Components. The RTE is ECU and application specific as it is generated individually for each [[ECU Configuration]]. One RTE is generated for each [[Partition]] (or core) of an ECU. [[Category:AUTOSAR]] [[Category:Software]] 57c668884989b69548920b64365a3dc8b414e975 1764 1754 2015-11-06T22:58:46Z Oliver 1 wikitext text/x-wiki The Runtime Environment (RTE) realizes the communication between [[Software Component|Software Components]] and the [[Basic Software]]. Software Components communicate with other components and/or [[Basic Software Module|Basic Software Modules]] exclusively via the RTE, which allows Software Components to be independent of any specific [[ECU]] and other Software Components. The RTE is ECU and application specific as it is generated individually for each [[ECU Configuration]]. One RTE is generated for each [[Partition]] (or core) of an ECU. = Communication Paradigms = AUTOSAR supports two basic communication paradigms: * [[Client-Server communication]] * [[Sender-Receiver communication]] Software Components communicate through well-defined [[Port|Ports]] and the behavior is statically defined by attributes. As this communication can cross different “borderlines”, the following Inter/Intra-Communication can be distinguished: * '''Inter-ECU communication''' Communication between Software Components mapped to different ECUs and is therefore concurrent and involves potentially unreliable communication. The communication mechanisms for the RTE are provided by the [[COM]] and the [[Communication Stack]]. * '''Intra-ECU communication''' Communication between Software Components mapped to the same ECU. ** '''Inter-Partition communication''' Communication between Software Components mapped to different [[Partition|Partitions]] of the same ECU. It involves a context switch and crossing a protection boundary (memory protection, timing protection, isolation on a core). The communication mechanisms for the RTE are provided by the [[IOC]]. Inter-Core communication is used for multi-core architectures and is similar to Inter-Partition communication. ** '''Intra-Partition Communication''' The communication remains inside the same Partition but [[Runnable Entity|Runnable Entities]] of a Software Component can be mapped to different [[Task|Tasks]]. *** '''Inter-Task Communication''' Communication between Runnable Entities mapped to different Tasks of the same Partition can involve a context switch. *** '''Intra-Task Communication''' Communication between Runnable Entities that are mapped to the same Task. In this case the generated RTE code for communication may simply consist of a direct function call or even direct data access (implemented though #defines). [[Category:AUTOSAR]] [[Category:Software]] 4a5ee0288290e61ad190ab60fdfbedfb797bc7ea 1765 1764 2015-11-06T22:59:31Z Oliver 1 /* Communication Paradigms */ wikitext text/x-wiki The Runtime Environment (RTE) realizes the communication between [[Software Component|Software Components]] and the [[Basic Software]]. Software Components communicate with other components and/or [[Basic Software Module|Basic Software Modules]] exclusively via the RTE, which allows Software Components to be independent of any specific [[ECU]] and other Software Components. The RTE is ECU and application specific as it is generated individually for each [[ECU Configuration]]. One RTE is generated for each [[Partition]] (or core) of an ECU. = Communication Paradigms = AUTOSAR supports two basic communication paradigms: * [[Client-Server Communication]] * [[Sender-Receiver Communication]] Software Components communicate through well-defined [[Port|Ports]] and the behavior is statically defined by attributes. As this communication can cross different “borderlines”, the following Inter/Intra-Communication can be distinguished: * '''Inter-ECU communication''' Communication between Software Components mapped to different ECUs and is therefore concurrent and involves potentially unreliable communication. The communication mechanisms for the RTE are provided by the [[COM]] and the [[Communication Stack]]. * '''Intra-ECU communication''' Communication between Software Components mapped to the same ECU. ** '''Inter-Partition communication''' Communication between Software Components mapped to different [[Partition|Partitions]] of the same ECU. It involves a context switch and crossing a protection boundary (memory protection, timing protection, isolation on a core). The communication mechanisms for the RTE are provided by the [[IOC]]. Inter-Core communication is used for multi-core architectures and is similar to Inter-Partition communication. ** '''Intra-Partition Communication''' The communication remains inside the same Partition but [[Runnable Entity|Runnable Entities]] of a Software Component can be mapped to different [[Task|Tasks]]. *** '''Inter-Task Communication''' Communication between Runnable Entities mapped to different Tasks of the same Partition can involve a context switch. *** '''Intra-Task Communication''' Communication between Runnable Entities that are mapped to the same Task. In this case the generated RTE code for communication may simply consist of a direct function call or even direct data access (implemented though #defines). [[Category:AUTOSAR]] [[Category:Software]] 8b6b339a5290012b429cd3ea73fb7551d337016d 0 394 1755 777 2015-11-06T22:36:47Z Oliver 1 Redirected page to [[ComplexDeviceDriverSwComponentType]] wikitext text/x-wiki #REDIRECT [[ComplexDeviceDriverSwComponentType]] 5e0da394abf19d858e932832c95238667efdb3a3 0 997 1757 2015-11-06T22:39:30Z Oliver 1 Created page with "The Basic Software Module Description (BSWMD) contains the configuration details of a [[Basic Software Module]]. It is an output of the [[RTE Generator]] during the RTE Genera..." wikitext text/x-wiki The Basic Software Module Description (BSWMD) contains the configuration details of a [[Basic Software Module]]. It is an output of the [[RTE Generator]] during the RTE Generation Phase. [[Category:AUTOSAR]] [[Category:Software]] d3f8e10a98db5d6949ba5d7db1bca65fd0ef5121 0 998 1758 2015-11-06T22:39:54Z Oliver 1 Redirected page to [[ARPackage]] wikitext text/x-wiki #REDIRECT [[ARPackage]] 0a8f3fa2cfecf2b1d9fdbb853a6d120ccd1d44e0 0 999 1759 2015-11-06T22:42:25Z Oliver 1 Created page with "An AUTOSAR Package (ARPackage) is some kind of “bundle” in order to group [[Software Component|Software Components]], Data Types and other elements of AUTOSAR. It creates..." wikitext text/x-wiki An AUTOSAR Package (ARPackage) is some kind of “bundle” in order to group [[Software Component|Software Components]], Data Types and other elements of AUTOSAR. It creates a corresponding “namespace” for this package. AUTOSAR standard elements are provided in a package of their own in order to distinguish which elements are standardized, e.g. package “AUTOSAR_Platform”. The (optional) category of a package defines whether it is used for reference or for processing: * BLUEPRINT: Elements in such a package act as a kind of “blueprint” like a toolbox from which the definitions can be copied to a real project. * STANDARD: Elements which are standardized by the submitter of the related top level package and can be used as is for processing (e.g. ECU Parameter definitions). * ICS: Elements which form an Implementation Conformance Statement that describes a set of one or more fully configured Software Modules. An ICS package is not allowed to provide sub packages with the category BLUEPRINT. * EXAMPLE: Examples how to apply elements in STANDARD or BLUEPRINT packages. [[Category:AUTOSAR]] [[Category:Software]] 6ee7d8e28f25eb0a30b26498cfa2cf87e12588b8 0 614 1760 1483 2015-11-06T22:44:21Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[AUTOSAR]] defines types and prototypes. This concept allows re-using elements (like [[Software Component]]s, [[Data Type]]s) several times. E.g. a SW-C type defines the properties of the SW-C together with the [[port]]s, [[internal behavior]] etc. The SW-C prototype is the usage of a SW-C type. The prototype contains all elements and properties of the type plus additional properties such as the [[shortName]]. A prototype is referencing a type and reuses its properties. In analogy to C++ the type would be the class and the prototype the instantiation of this class. 3a63c92f1137012ce07c3abaf681f1bd334e48dc 0 1000 1761 2015-11-06T22:45:32Z Oliver 1 Created page with "The Short Name (shortName) of an AUTOSAR element is used as an Identifier for referencing the element (e.g. from other elements). The following requirements for a shortName ap..." wikitext text/x-wiki The Short Name (shortName) of an AUTOSAR element is used as an Identifier for referencing the element (e.g. from other elements). The following requirements for a shortName apply. It shall be * unique within an [[ARPackage]] * in English language * limited to 128 characters * without underscores (where the shortName is used for generated API names, e.g. [[PortPrototype|PortPrototypes]]) * start with a letter * suitable as a valid identifier in source code for C, C++ and C-preprocessor (e.g. C keywords are not allowed). [[Category:AUTOSAR]] [[Category:Software]] dc11aa8a987cc4eaabd7da268e6e8473042db0ca 1762 1761 2015-11-06T22:51:15Z Oliver 1 wikitext text/x-wiki The Short Name (shortName) of an AUTOSAR element is used as an Identifier for referencing the element (e.g. from other elements). The following requirements for a shortName apply. It shall be * unique within an [[ARPackage]] * in English language * limited to 128 characters * without underscores (where the shortName is used for generated API names, e.g. [[PortPrototype|PortPrototypes]]) * start with a letter * suitable as a valid identifier in source code for C, C++ and C-preprocessor (e.g. C keywords are not allowed). = Naming Conventions for shortName = The “SW C and System Modeling Guide” of the AUTOSAR specification suggests some naming conventions for the shortName of various model elements, namely * [[ApplicationDataType]] * [[AutosarDataPrototype]] * [[CompuMethod]] * [[Unit]] * [[PhysicalDimension]] * [[DataConstr]] * [[SwComponentType]] * [[SwComponentPrototype]] * [[PortPrototype]] * [[PortInterface]] * [[PortPrototypeBlueprints]] * [[Keywords]] Due to the fact that this modeling guide is quite extensive and well written any Software System Architect should read and understand the original AUTOSAR document AUTOSAR_TR_SWCModelingGuide.pdf which is located in the folder Application Interfaces / General / Auxiliary Material. Furthermore the Application Interfaces for the relevant domain should be considered for any new design. Nevertheless, the following provides a short overview of the naming convention topics: * For reasons of compatibility and future extensibility the shortName of types should end with a sequence number. For modifications on this type a new type is defined where the trailing number is increased. Example: For modifications on DtEngSpd1 a new AutosarDataType DtEngSpd2 is defined. (This rule is not applicable for PortPrototypes.) * For shortNames an abbreviated name should be used. Example: Spd instead of Speed * Semantic rules should be applied for a “FieldBlock” as a concatenation of ** Mean, environment or device (e.g. Fuel, Air, Accelerator) ** Action or physical type (e.g. Release, Speed) ** Condition qualifier (e.g. Old, Request) ** Index for compatibility and future extensibility as mentioned above ** And preposition for joining or separating naming patterns (e.g. EngSpdAndPosn) None of the semantic fields are mandatory and semantic fields can be repeated. Examples: GearAct, MirrMoveCmd, EngSpdMax * For shortNames where no appropriate name can be found some standard names should be used: ** For VariableDataPrototypes of a SenderReceiverInterface: Val (for Value) ** For ClientServerOperation: Oper (for Operation) ** Repeating the shortName of the enclosing interface in the shortName of the data element is allowed, but not recommended. ** No numbers shall be used in the shortName of ApplicationArrayDataTypes to specify its length. ** shortNames of PhysicalDimensions are built using a sequence of base physical quantities keyword abbreviations followed by numbers as exponents (“Neg” keyword abbreviation shall be used for negative number). Example: Len2M1TiNeg3 for NwtMtrPerSec (Nm/s) [[Category:AUTOSAR]] [[Category:Software]] b984f685ad1bed61fbd25739e2914557a45c4633 0 356 1763 1487 2015-11-06T22:53:11Z Oliver 1 wikitext text/x-wiki The concept of the Virtual Functional Bus (VFB) allows to model the communication between Software Components on System Level and to strictly separate the application software ([[Software Component|Software Components]]) from infrastructure ([[Basic Software Module|Basic Software Modules]]). All components are connected through the VFB which enables the Software Components to be developed and maintained independent of [[ECU]] specifics and details. Communication to and from other components outside their own ECU are “routed” though the [[Communication Stack]] of the [[Basic Software]]. [[Category:AUTOSAR]] [[Category:Software]] 096daa8905c7b76dce9a4fa19202945338f971e0 0 109 1766 1105 2015-11-06T23:00:30Z Oliver 1 wikitext text/x-wiki Asynchronous communication does not block the sending [[software entity]] (like a [[Runnable Entity]]). The sending software entity continues its operation without getting a response from the communication partner(s). There could be an acknowledgement by the communication system about the sending of the information. A later response to the sending software entity is possible. [[Category:AUTOSAR]] [[Category:Software]] 76c02b8cbcff14bd96339d57822c4df3843bb0e6 0 111 1767 1108 2015-11-06T23:01:12Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Non-composed [[Software Component]] (SW-C). An Atomic Software Component might access [[HW]] or not, therefore not all Atomic SW-Cs are re-locatable. Any [[Software Component]] that can contain a SW-C [[internal behavior]]. An Atomic Software Component communicates with the outside via the [[interface]]s at the SW-C [[port]]s. Interrunnable communication is used for communication between Runnables of the same SW-C. The [[Runnable Entity|Runnable Entities]] have access to the same [[interrunnable variable]]. An [[Atomic Software Component]] cannot be further decomposed into smaller Software Components. 98252c07e91aef4b12504bb08bfb011716ae3e0a 0 302 1768 1452 2015-11-06T23:01:52Z Oliver 1 wikitext text/x-wiki An RTE [[Event]] encompasses all possible situations that can trigger execution of a [[Runnable Entity]] by the [[RTE]]. Thus they can address timing, data sending and receiving, invoking [[operation]]s, call [[server]] returning, [[mode switch]]ing, or external [[event]]s. RTE Events can either activate a Runnable entity or wakeup a Runnable Entity at its [[wait point]]s. Note ‘event’ in this context is not necessarily synonymous with ‘RTEEvent’ as defined in the [[VFB]] specification. In particular, RTE Events that result from communication are handled by communication-triggered runnable entities. An RTE event is part of an SW-C [[internal behavior]]. It defines situations and conditions for starting or continuing the execution of a specific [[runnable entity]]. = Timing event = Triggers a [[runnable entity]] periodically = Data received event = Triggers a runnable entity as soon as a [[variable data prototype]] is received at the [[port]]. [[Category:AUTOSAR]] [[Category:Software]] f0c90bb4177bb86a3bef399bedbb2efeef94e64a 0 309 1769 362 2015-11-06T23:02:16Z Oliver 1 wikitext text/x-wiki The scheduler handles the scheduling of the [[Task]]s/[[Runnable Entity|Runnable Entities]] according to the priority and scheduling policy (pre-defined or configurable). It has the responsibility to decide during [[run-time]] when which task can run on the [[CPU]] of the [[ECU]]. There are many strategies (priority-based, time-triggered, round-robbin, …) a scheduler can use, depending of the selected and/or implemented algorithms. af7f782d323b01c8b8286cfcba65d2376adf16d9 0 339 1770 951 2015-11-06T23:02:39Z Oliver 1 /* OS */ wikitext text/x-wiki = OS = A Task is the smallest schedulable unit managed by the [[OS]]. The OS decides when which task can run on the [[CPU]] of the [[ECU]]. A [[Runnable Entity]] of a [[software component]] runs in the context of a task. Also the [[Basic Software Module]]s runs in the context of a task. The OS task is an element that provided the framework for executing the [[ECU application]]. It can be executed [concurrently]] with other tasks. The [[task scheduler]] of the operating system controls the execution of an OS task according to the [[task priority]] and the task scheduling policy. == Basic Task == A basic task has a defined beginning and defined end. It releases the processor only if it is being terminated or if the operating system is executing a task with higher priority or if an [[interrupt]] occurs. A basic task can enter only the task states '''suspended''', '''ready''' and '''running'''. It cannot wait for [[OS event]]s. == Extended Task == Unlike a basic task an extended task can also enter the '''waiting''' task state in which it can wait for an OS event. = Methodology = According to the [[SPEM]] [[meta model]], a Task Definition is an assignable unit of work that is being performed by specific [[Role]]s. The duration of a task is generally a few hours to a few days. Tasks usually generate one or more [[work product]]s. Each Task is associated to input and output [[Work Product]]s. Inputs are differentiated in mandatory and optional inputs. A Task is used as one element among others to define a [[Process]]. A Task has a clear purpose in which the performing roles achieve a well defined goal. It provides complete step-by-step explanations of doing all the work that needs to be done to achieve this goal. This description is completely independent of when in a process lifecycle the work would actually be done. It does not describe when what work is being done, but describes all the work that gets done. When a Task is used in a process ([[Task Use]]), it provides the information of which pieces of the Task will actually be performed at any particular point in time. This assumes that the Task will be performed in the process over and over again, but each time with a slightly different emphasis on different steps or aspects of the task description. For the [[AUTOSAR Methodology]], a Task is a reusable element that is used across multiple methodology use cases. A Task is associated to at least one performing Role and may have several additional performers. Tasks use Tools to achieve their outputs. Optional performers and optional input and outputs to the task are described by the relationship’s multiplicity. cea8cb06364139666e24389ffbebb69329bad28a 0 397 1771 489 2015-11-06T23:02:52Z Oliver 1 Redirected page to [[Runnable Entity]] wikitext text/x-wiki #REDIRECT [[Runnable Entity]] 90367ea81c41db179820831f16b7538802190254 0 452 1772 1409 2015-11-06T23:04:01Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Function Inhibition [[Manager]] (FIM) is a [[Basic Software Module]] of the [[Diagnostic Services]]. The FiM stands for the evaluation and assignment of events to the required actions for [[Software Component]]s (e.g. inhibition of specific “Monitors”). The Function Inhibition Manager is responsible for providing a control mechanism for software components and the functionality therein. In this context, a functionality can be built up of the contents of one, several or parts of [[Runnable Entity|Runnable Entities]] with the same set of permission / [[inhibit condition]]s. By means of the FIM, the inhibiting of these functionalities can be configured and even modified by [[calibration]]. Therefore, the adaptation of a functionality into a new system context with modified physical boundary conditions and influences is significantly enhanced. A functionality in the sense of the FIM and a Runnable Entity are different and independent types of classifications. Runnable entities are mainly featured by their scheduling requirements. In contrast to that, functionalities are classified by their inhibit conditions. The services of the FIM focus on applications in the SW-Cs, however, they are not limited to them. Functionalities of the [[BSW]] can also use the FIM services. Note, there is no functional relationship between [[RTE]] and FIM. The RTE only provides communication in the sense that it connects the required ports of the SW components with the provided [[port]](s) of the FIM. But the RTE does not implement any functionality of the FIM. In contrast to that, the FIM deals with inhibit conditions and provides supporting mechanisms for controlling functionalities within Runnables via respective identifiers ([[FID]]). Therefore, the FIM and RTE concepts do not interfere with each other. === [[AUTOSAR Interface]] === === [[Standardized AUTOSAR Interface]] === Fim_GetFunctionPermission === [[Standardized Interface]] === Fim_DemTriggerOnEventStatus de297a6a97e8efe9d7149c6331653debd680b01a 0 649 1773 1474 2015-11-06T23:04:38Z Oliver 1 wikitext text/x-wiki The [[Software Component]] internal behavior represents the internal structure of an [[Atomic Software Component]]. It is characterized by its [[runnable entity|runnable entities]], [[RTE Event]]s, [[exclusive area]]s, [[Per instance memory]] and their interdependencies. The internal behavior is an element that represents the internal structure of an [[Atomic Software Component]]. It is characterized by [[elements]] such as * [[Runnable Entity|Runnable Entities]] * [[RTE Event]]s * [[data access definition]]s * [[Interrunnable Variable]]s and their interdependencies. A SW-C internal behavior is refined by a [[Software Component Implementation]]. [[Category:AUTOSAR]] [[Category:Software]] 1c0bc992380998ce85a3bf292bf343713edb012f 0 653 1774 1539 2015-11-06T23:04:55Z Oliver 1 wikitext text/x-wiki Wait points are a characteristic of a [[Runnable Entity]] that specifies that the [[operation system]] blocks the [[runnable]] execution at the specific code position of the [[RTE macro]] until a specific [[RTE Event]] occurs. [[Category:AUTOSAR]] 5f8dc3c3d5b002bfaa4f70635211abbbbe3f4e65 0 655 1775 990 2015-11-06T23:05:13Z Oliver 1 wikitext text/x-wiki The data access definition defines a [[Runnable Entity|Runnable Entities]] read or write access to communication data. A runnable entity can access communication data that is transferred between [[Software Component]]s via [[Sender-Receiver Interface]] or [[Client-Server Interface]]s. In addition a runnable entity can access [[interrunnable variable]]s that specify data that is transferred between runnable entities of one SW-C. 80c2ca0b7cde6d4228c2397b31c47d253f1d47d6 0 1001 1776 2015-11-06T23:05:49Z Oliver 1 Created page with "[[Category:AUTOSAR]] A Runnable Entity is a part of an [[Atomic Software Component]] which can be executed and scheduled independently from the other Runnable Entities of this..." wikitext text/x-wiki [[Category:AUTOSAR]] A Runnable Entity is a part of an [[Atomic Software Component]] which can be executed and scheduled independently from the other Runnable Entities of this Atomic Software-Component. It is described by a sequence of instructions that can be started by the [[RTE]]. Each runnable entity is associated with exactly one [[Entry Point]]. A Runnable Entity contains at least two points for the [[Scheduler]]: One [[Entry Point]] and one [[Exit Point]]. Due to the reason that an Atomic Software Component is not dividable, all its Runnable Entities are executed on the same [[ECU]]. A runnable entity is a sequence of instructions (provided by the component) that can be started by the Run-Time Environment. It runs in the context of a [[task]]. Runnables are the active parts of [[Software Component]]s. They can be executed [[concurrently]], by mapping them to different [[Task]]s. An runnable entity is part of a SW-C [[internal behavior]]. With regard to code execution a runnable is the smallest unit that can be scheduled and executed. Each runnable is implemented by exactly one C-function. They are the smallest units provided by the Software Component which can be triggered and executed by the RTE by a * [[RTE Event#Timing event|Timing event]] which triggers the runnable entity periodically * [[RTE Event#Data received event|Data received event]] which triggers the runnable entity as soon as a [[variable data prototype]] is received at the [[port]]. b91f065761445f4080925a5f3461efae448749e8 1777 1776 2015-11-06T23:06:01Z Oliver 1 wikitext text/x-wiki A Runnable Entity is a part of an [[Atomic Software Component]] which can be executed and scheduled independently from the other Runnable Entities of this Atomic Software-Component. It is described by a sequence of instructions that can be started by the [[RTE]]. Each runnable entity is associated with exactly one [[Entry Point]]. A Runnable Entity contains at least two points for the [[Scheduler]]: One [[Entry Point]] and one [[Exit Point]]. Due to the reason that an Atomic Software Component is not dividable, all its Runnable Entities are executed on the same [[ECU]]. A runnable entity is a sequence of instructions (provided by the component) that can be started by the Run-Time Environment. It runs in the context of a [[task]]. Runnables are the active parts of [[Software Component]]s. They can be executed [[concurrently]], by mapping them to different [[Task]]s. An runnable entity is part of a SW-C [[internal behavior]]. With regard to code execution a runnable is the smallest unit that can be scheduled and executed. Each runnable is implemented by exactly one C-function. They are the smallest units provided by the Software Component which can be triggered and executed by the RTE by a * [[RTE Event#Timing event|Timing event]] which triggers the runnable entity periodically * [[RTE Event#Data received event|Data received event]] which triggers the runnable entity as soon as a [[variable data prototype]] is received at the [[port]]. [[Category:AUTOSAR]] [[Category:Software]] eba210f5b591bbaebfeecbee8d14c0a8ec50bcfe 0 1002 1778 2015-11-07T21:38:23Z Oliver 1 Redirected page to [[AutosarDataType]] wikitext text/x-wiki #REDIRECT [[AutosarDataType]] 615a6193dd35b23b4fceaca3b106f16f569ac39b 0 1003 1779 2015-11-07T21:42:15Z Oliver 1 Redirected page to [[AutosarDataType#SwDataDefProps]] wikitext text/x-wiki #REDIRECT [[AutosarDataType#SwDataDefProps]] cabdffda9d0775a9cde34c8bbaccece19b9eb769 0 1004 1780 2015-11-07T21:45:23Z Oliver 1 Created page with "Display formats (DisplayFormatString) are used for [[SwDataDefProps]] and [[CompuMethod]] to specify the display format of values in documents or measurement and calibration s..." wikitext text/x-wiki Display formats (DisplayFormatString) are used for [[SwDataDefProps]] and [[CompuMethod]] to specify the display format of values in documents or measurement and calibration systems. It consists of a subset of the ANSI C [[wikipedia:Printf_format_string|printf]] specifiers:<br /> % [flags][width][.prec]type [[Category:AUTOSAR]] [[Category:Software]] e0cff81097271ff5ff23716a09603ca01529d411 0 1005 1781 2015-11-07T21:45:52Z Oliver 1 Redirected page to [[DisplayFormatString]] wikitext text/x-wiki #REDIRECT [[DisplayFormatString]] f3c1cf9e78a704e3b499347234826e00f27e84ff 0 1006 1782 2015-11-07T21:46:16Z Oliver 1 Redirected page to [[DisplayFormatString]] wikitext text/x-wiki #REDIRECT [[DisplayFormatString]] f3c1cf9e78a704e3b499347234826e00f27e84ff 0 1007 1783 2015-11-07T21:47:48Z Oliver 1 Created page with "The attribute swAlignment defines the alignment of the [[AutosarDataPrototype]]. If the attribute is not defined then the alignment is determined by the size ([[baseTypeSize]..." wikitext text/x-wiki The attribute swAlignment defines the alignment of the [[AutosarDataPrototype]]. If the attribute is not defined then the alignment is determined by the size ([[baseTypeSize]]) of the [[SwBaseType]] and the [[memoryAllocationKeywordPolicy]] of the referenced [[SwAddrMethod]]. The swAlignment of an [[ImplementationDataType]] with category [[STRUCT]] or [[UNION]] must be set to the biggest baseTypeSize of the SwBaseTypes used by the elements. The alignment of an ImplementationDataType with category [[TYPE_REFERENCE]] is defined by the referenced ImplementationDataType. [[Category:AUTOSAR]] [[Category:Software]] 69642e9b39fa8456ac31bddcf06a7c140f81371b 0 1008 1784 2015-11-07T21:48:20Z Oliver 1 Redirected page to [[SwAlignment]] wikitext text/x-wiki #REDIRECT [[swAlignment]] 29fb2d4f1a7dec91a919c1d9cdede766af9e14f3 0 1009 1785 2015-11-07T21:49:52Z Oliver 1 Redirected page to [[CseCodeType]] wikitext text/x-wiki #REDIRECT [[CseCodeType]] 5b357fc67a7b43d66b3655a79c3d757b6c5bc71e 0 1010 1786 2015-11-07T21:50:16Z Oliver 1 Redirected page to [[CseCodeType]] wikitext text/x-wiki #REDIRECT [[CseCodeType]] 5b357fc67a7b43d66b3655a79c3d757b6c5bc71e 0 1011 1787 2015-11-07T21:51:10Z Oliver 1 Redirected page to [[CseCodeType]] wikitext text/x-wiki #REDIRECT [[CseCodeType]] 5b357fc67a7b43d66b3655a79c3d757b6c5bc71e 0 1012 1788 2015-11-07T21:51:37Z Oliver 1 Redirected page to [[CseCodeType]] wikitext text/x-wiki #REDIRECT [[CseCodeType]] 5b357fc67a7b43d66b3655a79c3d757b6c5bc71e 0 1013 1789 2015-11-07T21:52:17Z Oliver 1 Created page with "The CSE Code Type and Factor (MultidimensionalTime, CseCodeType, CseCodeFactor) specifies the time base by means of CseCodeType (based on ASAM CSE codes): * 0: 1 µs * 1: 10..." wikitext text/x-wiki The CSE Code Type and Factor (MultidimensionalTime, CseCodeType, CseCodeFactor) specifies the time base by means of CseCodeType (based on ASAM CSE codes): * 0: 1 µs * 1: 10 µs * 2: 100 µs * 3: 1 ms * 4: 10 ms * 5: 100 ms * 6: 1 s * 7: 10 s * 8: 1 minute * 9: 1 hour * 10: 1 day * 100: Angular degrees * 101: Revolutions 360 degrees * 102: Cycle 720 degrees * 103: Cylinder segment * 998: When frame available * 999: Always if there is new value * 1000: Non deterministic 89e145addc65d292fd1a50b135c7806279cbaaff 0 1014 1790 2015-11-07T21:58:30Z Oliver 1 Created page with "Similar to other programming languages like “C”, variables need to be defined by some data type. The idea is to keep the Application Level as independent from Implementati..." wikitext text/x-wiki Similar to other programming languages like “C”, variables need to be defined by some data type. The idea is to keep the Application Level as independent from Implementation Level as possible. Therefore in AUTOSAR 4 the ApplicationDataTypes have been introduced.<br /> The variables that are defined by ApplicationDataTypes are called [[AutosarDataPrototype|AutosarDataPrototypes]] (in C++ you would call it an instance of the class, or an instance of the data type). All ApplicationDataTypes and ImplementationDataTypes are derived from an AutosarDataType and mapped to each other by [[DataTypeMap|DataTypeMaps]].<br /> = SwDataDefProps = The properties of an AutosarDataType (and therefore all ApplicationDataTypes and ImplementationDataTypes) can be defined as SwDataDefProps, whereas only a subset of the properties of SwDataDefProps are applicable for specific data types, dependent on the category. As SwDataDefProps can be defined for several different AUTOSAR elements, the following priority is valid. Properties of a lower number overwrite properties of higher number: 1. [[McDataInstance]] 2. [[FlatInstanceDescriptor]] 3. [[ParameterAccess]] 4. [[InstantiationDataDefProps]] 5. [[AutosarDataPrototype]] 6. [[ImplementationDataType]] 7. [[ApplicationDataType]] <br /> SwDataDefProps are compatible if the following properties are compatible: * compuMethod.compuPhysToInternal * compuMethod.compuInternalToPhys * dataConstr * invalidValue (same value) * swRecordLayout * unit = Application Data Level (ApplicationDataType) = On Application Data Level ApplicationDataTypes and their AutosarDataPrototypes for ApplicationSwComponentTypes are defined from the application point of view. On this level no implementation details such as bit-size, endianness, etc. are defined so that a [[VFB]] system can be defined by using ApplicationDataTypes only. For integration of the [[Software Component|Software Components]] into the [[ECU]] the ApplicationDataTypes must be mapped to ImplementationDatatypes. An ApplicationDataType is further derived into * ApplicationPrimitiveDataType * ApplicationCompositeDataType ** ApplicationRecordDataType: Equivalent to a struct {} in C language. ** ApplicationArrayDataType: Equivalent to an array [] in C language. The category parameter of an ApplicationDataType is used to define the nature of this data type on application level: {| class="wikitable" |category || Description |- |VALUE || Primitive value. |- |STRUCTURE || A data structure (Record) that contains one or more data elements. Note that these ApplicationRecordElements need to have the same SwAddrMethod (→10.7) defined. |- |ARRAY || A data structure where all ApplicationArrayElements are of the same ApplicationDataType. |- |STRING || Contains a single value interpreted as a text string. |- |VAL_BLK || Same as ARRAY. Only that from Measurement & Calibration point-of-view it is interpreted as an axis. |- |BOOLEAN || Contains a boolean state: TRUE or FALSE. |- |COM_AXIS || A common axis as separate calibration parameter which can be referenced by a CURVE or MAP. |- |RES_AXIS || A rescale axis is a shared axis like COM_AXIS. The difference is that this kind of axis can be used for rescaling. Note that the RES_AXIS is by nature a CURVE which is used to implement a nonlinear scaling (rescale) of the axis. |- |CURVE || Calibration parameter with one input value and one output value. The granularity of implemented functionality can be changed by using different number of axis points. A CURVE has always one input axis and one output axis. The output axis is a characteristic of the curve and every time present but the input axis can be defined within the curve definition or separately. |- |MAP || Calibration parameter with two input values and one output value. The granularity of implemented functionality can be changed by using different number of axis points for y- and x-axis. A MAP has always two input axes and one output axis. The output axis is a characteristic of the map and every time present but the input axes can be defined within the map definition or separately. |} 1d4f3062fea75297c511e70e8a941aaa66ee670d 1791 1790 2015-11-07T22:08:13Z Oliver 1 wikitext text/x-wiki Similar to other programming languages like “C”, variables need to be defined by some data type. The idea is to keep the Application Level as independent from Implementation Level as possible. Therefore in AUTOSAR 4 the ApplicationDataTypes have been introduced.<br /> The variables that are defined by ApplicationDataTypes are called [[AutosarDataPrototype|AutosarDataPrototypes]] (in C++ you would call it an instance of the class, or an instance of the data type). All ApplicationDataTypes and ImplementationDataTypes are derived from an AutosarDataType and mapped to each other by [[DataTypeMap|DataTypeMaps]].<br /> = SwDataDefProps = The properties of an AutosarDataType (and therefore all ApplicationDataTypes and ImplementationDataTypes) can be defined as SwDataDefProps, whereas only a subset of the properties of SwDataDefProps are applicable for specific data types, dependent on the category. As SwDataDefProps can be defined for several different AUTOSAR elements, the following priority is valid. Properties of a lower number overwrite properties of higher number: 1. [[McDataInstance]] 2. [[FlatInstanceDescriptor]] 3. [[ParameterAccess]] 4. [[InstantiationDataDefProps]] 5. [[AutosarDataPrototype]] 6. [[ImplementationDataType]] 7. [[ApplicationDataType]] <br /> SwDataDefProps are compatible if the following properties are compatible: * compuMethod.compuPhysToInternal * compuMethod.compuInternalToPhys * dataConstr * invalidValue (same value) * swRecordLayout * unit = Application Data Level (ApplicationDataType) = On Application Data Level ApplicationDataTypes and their AutosarDataPrototypes for ApplicationSwComponentTypes are defined from the application point of view. On this level no implementation details such as bit-size, endianness, etc. are defined so that a [[VFB]] system can be defined by using ApplicationDataTypes only. For integration of the [[Software Component|Software Components]] into the [[ECU]] the ApplicationDataTypes must be mapped to ImplementationDatatypes. An ApplicationDataType is further derived into * ApplicationPrimitiveDataType * ApplicationCompositeDataType ** ApplicationRecordDataType: Equivalent to a struct {} in C language. ** ApplicationArrayDataType: Equivalent to an array [] in C language. The category parameter of an ApplicationDataType is used to define the nature of this data type on application level: {| class="wikitable" |category || Description |- |VALUE || Primitive value. |- |STRUCTURE || A data structure (Record) that contains one or more data elements. Note that these ApplicationRecordElements need to have the same SwAddrMethod (→10.7) defined. |- |ARRAY || A data structure where all ApplicationArrayElements are of the same ApplicationDataType. |- |STRING || Contains a single value interpreted as a text string. |- |VAL_BLK || Same as ARRAY. Only that from Measurement & Calibration point-of-view it is interpreted as an axis. |- |BOOLEAN || Contains a boolean state: TRUE or FALSE. |- |COM_AXIS || A common axis as separate calibration parameter which can be referenced by a CURVE or MAP. |- |RES_AXIS || A rescale axis is a shared axis like COM_AXIS. The difference is that this kind of axis can be used for rescaling. Note that the RES_AXIS is by nature a CURVE which is used to implement a nonlinear scaling (rescale) of the axis. |- |CURVE || Calibration parameter with one input value and one output value. The granularity of implemented functionality can be changed by using different number of axis points. A CURVE has always one input axis and one output axis. The output axis is a characteristic of the curve and every time present but the input axis can be defined within the curve definition or separately. |- |MAP || Calibration parameter with two input values and one output value. The granularity of implemented functionality can be changed by using different number of axis points for y- and x-axis. A MAP has always two input axes and one output axis. The output axis is a characteristic of the map and every time present but the input axes can be defined within the map definition or separately. |} == Application Primitive Data Types (ApplicationPrimitiveDataType) == === ApplicationDataType for Calibration Parameters === Data types for calibration parameters are always described as ApplicationPrimitiveDataTypes, even if they have an internal structure. Their substructure is attached to the SwDataDefProps and needs a special description in order to be compatible with existing calibration techniques (instead of a composition of other AutosarDataTypes) === ApplicationDataType for Single Values (VALUE) === The value of the parameter category is set to VALUE. === ApplicationDataType for Enumerations (VALUE) === An enumeration is usually implemented by using an ApplicationPrimitiveDataType of category VALUE. The mapping of the integer numbers to the enum labels is accomplished via an attached [[CompuMethod]], which is of category [[TEXTTABLE]] . === ApplicationDataType for Textual Strings (STRING) === An ApplicationDataType of category STRING contains a text string that is interpreted as a single value on Application Level. On Implementation Level it is usually represented as an [[ARRAY]] or a [[STRUCTURE]]. Note that both, the ApplicationPrimitiveDataType as well as the ImplementationDataType have to reference the same SwBaseType. === ApplicationDataType for Value Blocks (VAL_BLK) === A Value Block (VAL_BLK) is similar to a Value Array but defines values on an axis (only important for calibration data handling). It is mapped to an [[ARRAY]] on Implementation Data Level. === ApplicationDataType for Boolean (BOOLEAN) === An ApplicationDataType for Boolean is mapped to a [[VALUE]] on Implementation Data Level. === ApplicationDataType for Common Axis (COM_AXIS) === A Common Axis definition is a separate calibration parameter which can be referenced by any [[CURVE]] or [[MAP]]. The benefits by using a common axis is that it saves memory space, because it is stored only one time and can be used in multiple curves or maps. It is mapped to an [[ARRAY]] on Implementation Data Level. === ApplicationDataType for Rescale Axis (RES_AXIS) === A Rescale Axis is also a shared axis like [[COM_AXIS]], the difference is that this kind of axis can be used for rescaling. Note that the RES_AXIS is by nature a [[CURVE]] which is used to implement a nonlinear scaling (rescale) of the axis. In addition to saving memory space via the shared usage like a COM_AXIS, it can compress a huge range to non-linear distributed axis points thus retaining the required accuracy. It is mapped to an [[ARRAY]] on Implementation Data Level. === ApplicationDataType for a Curve (CURVE) === A Curve is a calibration parameter with one input value and one output value. That means output values can be defined depending on the input value. The granularity of implemented functionality can be changed by using different number of axis points. A CURVE has always one input axis and one output axis. The output axis is a characteristic of the curve and every time present but the input axis can be defined within the curve definition or separately. It is mapped to an [[ARRAY]] on Implementation Data Level. === ApplicationDataType for a Map (MAP) === A Map is a calibration parameter with two input values and one output value. That means output values can be defined depending on the input values .The granularity of implemented functionality can be changed by using different number of axis points for y- and x-axis. A MAP has always two input axes and one output axis. The output axis is a characteristic of the map and every time present but the input axes can be defined within the map definition or separately. == Application Composite Data Type (ApplicationCompositeDataType) == Similar to programming languages like “C” structures and data arrays can be defined on Application Data Level via ApplicationCompositeDataTypes. The corresponding types are ApplicationRecordDataTypes, or ApplicationArrayDataTypes. ApplicationRecordDataTypes can contain * ApplicationPrimitiveDataTypes, * ApplicationArrayDataTypes or * other ApplicationRecordDataTypes. === ApplicationRecordDataType (STRUCTURE) === An ApplicationRecordDataType is a compilation of ApplicationRecordElements which themselves are ApplicationDataTypes. An ApplicationRecordElement can be of the following category: [[VALUE]], [[VAL_BLK]], [[STRUCTURE]], [[ARRAY]], [[STRING]], [[BOOLEAN]], [[CURVE]], [[MAP]] The category of an ApplicationRecordDataType has to be set to STRUCTURE. All ApplicationRecordElements need to have the same value configured for [[SwAddrMethod]]. === ApplicationArrayDataType (ARRAY) === An ApplicationArrayDataType consists of one or more ApplicationArrayElements of the same ApplicationDataType. Dependent on the attribute arraySizeSemantics, the number of elements of the ApplicationArrayDataType might vary at run-time between 0 and maxNumberOfElements. The category of an ApplicationArrayElement must be identical to the category of the AutosarDataType that is referenced. It can be of the following category: [[VALUE]], [[VAL_BLK]], [[STRUCTURE]], [[ARRAY]], [[STRING]], [[BOOLEAN]], [[COM_AXIS]], [[RES_AXIS]], [[CURVE]], [[MAP]] For multi-dimensional arrays, an element references another ApplicationArrayDataType. 3741325808aa2c7de7c0f276aee4d2470d8ccfe0 0 1015 1792 2015-11-11T08:12:23Z Oliver 1 Redirected page to [[wikipedia:Application lifecycle management]] wikitext text/x-wiki #REDIRECT [[wikipedia:Application_lifecycle_management|Application Lifecycle Management]] a52e2577631918cc60f24a96812058d079f1310e 0 716 1793 1143 2015-11-13T10:20:33Z Oliver 1 Redirected page to [[Audio Video Bridging]] wikitext text/x-wiki #REDIRECT [[Audio Video Bridging]] 065dee2827e66f65454c0cd70f7cfe049560c6e3 0 1016 1794 2015-11-13T10:21:07Z Oliver 1 Redirected page to [[wikipedia:Audio Video Bridging]] wikitext text/x-wiki #REDIRECT [[wikipedia:Audio Video Bridging|Audio Video Bridging]] f2a3b1ab1d70b28e53f9d7707d9e4242742e2e87 0 1017 1795 2015-11-13T13:34:39Z Oliver 1 Redirected page to [[wikipedia:ISO/IEC 15504]] wikitext text/x-wiki #REDIRECT [[wikipedia:ISO/IEC_15504|automotive SPICE]] 15a1a5b3f914db96a1cdb737c82b1aa16e173af6 0 1018 1796 2015-11-13T13:36:02Z Oliver 1 Redirected page to [[wikipedia:ISO/IEC 15504]] wikitext text/x-wiki #REDIRECT [[wikipedia:ISO/IEC_15504|automotive SPICE]] 15a1a5b3f914db96a1cdb737c82b1aa16e173af6 0 1019 1797 2015-11-13T13:37:19Z Oliver 1 Redirected page to [[Computer-Aided Software Engineering]] wikitext text/x-wiki #REDIRECT [[Computer-Aided Software Engineering]] d513537c8f5f99dc75b8ed8e3e224fd87df191e7 0 1020 1798 2015-11-13T13:38:25Z Oliver 1 Redirected page to [[Call For Proposals]] wikitext text/x-wiki #REDIRECT [[Call For Proposals]] cd534ad2a26556f6302b440717af8696348b1669 0 364 1799 428 2015-11-13T13:39:46Z Oliver 1 Redirected page to [[wikipedia:EEPROM]] wikitext text/x-wiki #REDIRECT [[wikipedia:EEPROM|Electrically Erasable Programmable Read-Only Memory]] 691b493923320c281a4b72f438fdeab18f6ad6a1 0 593 1800 859 2015-11-13T13:43:55Z Oliver 1 wikitext text/x-wiki International Standardization Organization [http://www.ISO.org] e97822863a373c2fbe9f7152b6a81671e1949ac8 0 1021 1801 2015-11-13T13:44:20Z Oliver 1 Redirected page to [[Invitation To Tender]] wikitext text/x-wiki #REDIRECT [[Invitation To Tender]] c3683fe1f06bcadf9dd346515aee5cae1c44eaa8 0 1022 1802 2015-11-13T13:44:55Z Oliver 1 Redirected page to [[Process Reference Model]] wikitext text/x-wiki #REDIRECT [[Process Reference Model]] f716a132c27d29519438db487a13d229addd25b5 0 1023 1803 2015-11-13T13:47:46Z Oliver 1 Created page with "[[SPICE]] User Group" wikitext text/x-wiki [[SPICE]] User Group 032462504af6fca62782eafab8b2611436112019 0 1024 1804 2015-11-13T13:50:13Z Oliver 1 Created page with "Formal testing conducted to enable a user, customer, or authorized entity to determine whether to accept a system or component.<br /> (from ISO/IEC/IEEE 24765)" wikitext text/x-wiki Formal testing conducted to enable a user, customer, or authorized entity to determine whether to accept a system or component.<br /> (from ISO/IEC/IEEE 24765) 478b7471ec944e9b9376e1f05c447bd5ca8af5e2 0 1025 1805 2015-11-13T13:50:58Z Oliver 1 Created page with "An application parameter is a parameter containing data applied to the system or software functions, behavior or properties. The notion of application parameter is expressed i..." wikitext text/x-wiki An application parameter is a parameter containing data applied to the system or software functions, behavior or properties. The notion of application parameter is expressed in two ways: firstly, the logical specification (including name, description, unit, value domain or threshold values or characteristic curves, respectively), and, secondly, the actual quantitative data value it receives by means of data application. (from Automotive SPICE V3.0) [[Category:Software]] 799ad96ff10d38e36ce3da8cc3650a3b8afcac08 0 1026 1806 2015-11-13T13:52:08Z Oliver 1 Created page with "Result of the decomposition of the architecture on system and software level: * The system is decomposed into elements of the system architecture across appropriate hierarchic..." wikitext text/x-wiki Result of the decomposition of the architecture on system and software level: * The system is decomposed into elements of the system architecture across appropriate hierarchical levels. * The software is decomposed into elements of the software architecture across appropriate hierarchical levels down to the [[Software Component|software components]] (the lowest level elements of the software architecture).<br /> (from Automotive SPICE V3.0) ef83f0912ef51f9277bbfacea0a0fb81b3be6694 0 1027 1807 2015-11-13T13:53:55Z Oliver 1 Created page with "A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and can be changed only through formal..." wikitext text/x-wiki A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and can be changed only through formal change control procedures.<br /> (from ISO/IEC/IEEE 24765) 432e371973fb8a9881f6aaa6ecf36b38187e3a07 0 1028 1808 2015-11-13T13:54:26Z Oliver 1 Created page with "Method of requirement testing where tests are developed without knowledge of the internal structure and mechanisms of the tested item.<br /> (from Automotive SPICE V3.0) Cat..." wikitext text/x-wiki Method of requirement testing where tests are developed without knowledge of the internal structure and mechanisms of the tested item.<br /> (from Automotive SPICE V3.0) [[Category:Software]] 4d8341519f81cf24ef981616d5c471ab1baad44f 1831 1808 2015-11-13T14:57:53Z Oliver 1 wikitext text/x-wiki Method of [[requirement]] testing where tests are developed without knowledge of the internal structure and mechanisms of the tested item.<br /> (from Automotive SPICE V3.0) [[Category:Software]] 642a0c8414ee74c8a8c5f7463e8bb66ee2cba12d 0 1029 1809 2015-11-13T13:54:56Z Oliver 1 Created page with "A check of the code by one or more qualified persons to determine its suitability for its intended use and identify discrepancies from specifications and standards.<br /> (fro..." wikitext text/x-wiki A check of the code by one or more qualified persons to determine its suitability for its intended use and identify discrepancies from specifications and standards.<br /> (from Automotive SPICE V3.0) [[Category:Software]] 0817c6305a30344cb115bdcfff1a99b6de6d4602 0 1030 1810 2015-11-13T13:56:27Z Oliver 1 Created page with "* [[Variant Coding]] * [[Programming Coding]] [[Category:Software]]" wikitext text/x-wiki * [[Variant Coding]] * [[Programming Coding]] [[Category:Software]] 0a81fcb055b867a2596311fd411e9380cb9e7400 0 1031 1811 2015-11-13T13:57:14Z Oliver 1 Created page with "The transforming of logic and data from design specifications (design descriptions) into programming language.<br /> (from ISO/IEC/IEEE 24765) [[Category:Software]]" wikitext text/x-wiki The transforming of logic and data from design specifications (design descriptions) into programming language.<br /> (from ISO/IEC/IEEE 24765) [[Category:Software]] 3a832bd8f8c97b4a45318d9bf79b688ec76047c0 0 1032 1812 2015-11-13T13:57:53Z Oliver 1 Created page with "Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.<br /..." wikitext text/x-wiki Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.<br /> (from [[Automotive SPICE]] V3.0) [[Category:Software]] f9ed47c4e1d4116a48d9347972601dd9bfafb415 0 1033 1813 2015-11-13T13:58:32Z Oliver 1 Created page with "A process of evaluating a system or component based on its behavior during execution.<br /> (from ISO/IEC/IEEE 24765) [[Category:Software]]" wikitext text/x-wiki A process of evaluating a system or component based on its behavior during execution.<br /> (from ISO/IEC/IEEE 24765) [[Category:Software]] acaec81827670c54508c0e7926793fbcfc7b8fe3 0 1034 1814 2015-11-13T13:59:32Z Oliver 1 Created page with "Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements..." wikitext text/x-wiki Elements are all structural objects on architectural and design level on the left side of the "V". Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.<br /> (from [[Automotive SPICE]] V3.0) [[Category:Software]] aec3fb67c883ae73de46d53afd7060c5569f6ed3 0 1035 1815 2015-11-13T14:03:10Z Oliver 1 Redirected page to [[Fault, Error, Failure]] wikitext text/x-wiki #REDIRECT [[Fault, Error, Failure]] 4da1a34a8a57547edeaa570ca3c44c7adf325581 0 176 1816 203 2015-11-13T14:03:24Z Oliver 1 Redirected page to [[Fault, Error, Failure]] wikitext text/x-wiki #REDIRECT [[Fault, Error, Failure]] 4da1a34a8a57547edeaa570ca3c44c7adf325581 0 164 1817 1009 2015-11-13T14:03:30Z Oliver 1 Redirected page to [[Fault, Error, Failure]] wikitext text/x-wiki #REDIRECT [[Fault, Error, Failure]] 4da1a34a8a57547edeaa570ca3c44c7adf325581 0 174 1818 198 2015-11-13T14:04:05Z Oliver 1 Redirected page to [[Fault, Error, Failure]] wikitext text/x-wiki #REDIRECT [[Fault, Error, Failure]] 4da1a34a8a57547edeaa570ca3c44c7adf325581 0 1036 1819 2015-11-13T14:06:22Z Oliver 1 Created page with "fault => error => failure = Fault = Abnormal condition (or defect) that can cause an [[element]] or an [[item]] to fail.<br /> Note that according to ISO/IEC/IEEE 24765 a Fau..." wikitext text/x-wiki fault => error => failure = Fault = Abnormal condition (or defect) that can cause an [[element]] or an [[item]] to fail.<br /> Note that according to ISO/IEC/IEEE 24765 a Fault is a "A manifestation of an error in software.", which would be a failure in the definition of this wiki. = Error = Discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition. An error can arise as a result of unforeseen operating conditions or due to a [[fault]] within the system, [[subsystem]] or [[component]] being considered. A fault can manifest itself as an error within the considered [[element]] and, at the end of its latency, the error can cause a [[failure]]. As errors are faults that have been activated and propagated, a single error can (theoretically) have many possible root causes, i.e., faults. = Failure (Defect) = Termination of the ability of an [[element]] or an [[item]] to perform a function as required. Termination is a reduction in, or loss of, ability of an element or an item to perform a function as required. There is a difference between “to perform a function as required” (stronger definition, use-oriented) and ”to perform a function as specified”, so a failure can result from an incorrect specification. db238d33c9695258e278119489239398c42fbc9d 0 1037 1820 2015-11-13T14:06:59Z Oliver 1 Created page with "A statement that identifies what a product or process must accomplish to produce required behavior and/or results.<br /> (from ISO/IEC/IEEE 24765)" wikitext text/x-wiki A statement that identifies what a product or process must accomplish to produce required behavior and/or results.<br /> (from ISO/IEC/IEEE 24765) f7b61d1d2ae401ec1bd3a00bf0ecb5ae0aa53565 0 1038 1821 2015-11-13T14:07:21Z Oliver 1 Created page with "A document that specifies the functions that a system or component must perform. Often part of a requirements specification.<br /> (from ISO/IEC/IEEE 24765)" wikitext text/x-wiki A document that specifies the functions that a system or component must perform. Often part of a requirements specification.<br /> (from ISO/IEC/IEEE 24765) 0323ea2c0f07218a00e9ba7a6b6b94e98e96079d 0 1039 1822 2015-11-13T14:07:39Z Oliver 1 Created page with "Testing conducted to evaluate the compliance of a system or component with specified functional requirements.<br /> (from ISO/IEC/IEEE 24765)" wikitext text/x-wiki Testing conducted to evaluate the compliance of a system or component with specified functional requirements.<br /> (from ISO/IEC/IEEE 24765) ace408623184fc77b81c64e8ea124f17808a38dd 0 1040 1823 2015-11-13T14:08:10Z Oliver 1 Created page with "Physical equipment used to process, store, or transmit computer programs or data.<br /> (from ISO/IEC/IEEE 24765) [[Category:Hardware]]" wikitext text/x-wiki Physical equipment used to process, store, or transmit computer programs or data.<br /> (from ISO/IEC/IEEE 24765) [[Category:Hardware]] 7eced1834247578e147e4d487e3bf365747f9950 0 1041 1824 2015-11-13T14:09:33Z Oliver 1 Created page with "A physical representation of a [[hardware]] element.<br /> (from [[Automotive SPICE]] V3.0) [[Category:Hardware]]" wikitext text/x-wiki A physical representation of a [[hardware]] element.<br /> (from [[Automotive SPICE]] V3.0) [[Category:Hardware]] b32fa11873e1b3fddb4a85deceeada95e6f5bac9 0 238 1825 276 2015-11-13T14:10:14Z Oliver 1 wikitext text/x-wiki The progressive assembling of [[system component]]s into the whole [[system]].<br /> <br /> A process of combining items to larger items up to an overall system.<br /> (from [[Automotive SPICE]] V3.0) acc85627eda9d0683ddf8edacf230b9e02d682f7 0 1042 1826 2015-11-13T14:11:02Z Oliver 1 Created page with "A set of software units or items that are integrated into a larger assembly for the purpose of [[integration testing]].<br /> (from [[Automotive SPICE]] V3.0) Category:Softw..." wikitext text/x-wiki A set of software units or items that are integrated into a larger assembly for the purpose of [[integration testing]].<br /> (from [[Automotive SPICE]] V3.0) [[Category:Software]] 955292c18170972e1a8f1c45846f20201e236120 0 1043 1827 2015-11-13T14:12:20Z Oliver 1 Created page with "Testing in which items ([[Software item|software items]], [[Hardware item|hardware items]], or [[System item|system items]]) are combined and tested to evaluate the interactio..." wikitext text/x-wiki Testing in which items ([[Software item|software items]], [[Hardware item|hardware items]], or [[System item|system items]]) are combined and tested to evaluate the interaction among them.<br /> (from [[Automotive SPICE]] V3.0) 3970da7598b565775856364bb3a148ae8b2e40ef 0 1044 1828 2015-11-13T14:13:01Z Oliver 1 Created page with "A set of items that are integrated into a larger assembly for the purpose of [[Integration testing|integration testing]].<br /> (from [[Automotive SPICE]] V3.0)" wikitext text/x-wiki A set of items that are integrated into a larger assembly for the purpose of [[Integration testing|integration testing]].<br /> (from [[Automotive SPICE]] V3.0) 2fafe6b96b88bc4b765da9d7fdc6952715772b90 0 1045 1829 2015-11-13T14:13:34Z Oliver 1 Created page with "A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements.<br /> (from IS..." wikitext text/x-wiki A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements.<br /> (from ISO/IEC/IEEE 24765) 5d4b7acdb1613c20df0fc568db2986bd9e1e0e66 0 1046 1830 2015-11-13T14:14:04Z Oliver 1 Created page with "Selective retesting of a system or item to verify that modifications have not caused unintended effects and that the system or item still complies with its specified requireme..." wikitext text/x-wiki Selective retesting of a system or item to verify that modifications have not caused unintended effects and that the system or item still complies with its specified requirements.<br /> (from [[Automotive SPICE]] V3.0) cef031bf949095d305adc5bd084bc780661b2ce9 0 810 1832 1254 2015-11-13T14:58:13Z Oliver 1 wikitext text/x-wiki Lastenheft => Customer [[Requirement Specification]] 0784a7d975c15ae0e45fbba7e86565744fdefb9b 0 787 1833 1224 2015-11-13T14:58:34Z Oliver 1 wikitext text/x-wiki (Sub-)system [[Requirement]] Document. 93f95566de025778530d83de18cdd870278644b4 0 354 1834 506 2015-11-13T14:59:10Z Oliver 1 wikitext text/x-wiki Confirmation by examination and provisions of objective evidence that specified [[Requirement|requirements]] have been fulfilled. In design and development, verification concerns the process of examining the result of a given [[activity]] to determine conformity with the stated requirement for that activity. “Verified” is used to designate the corresponding status. [ISO 8402: 1994] b782ce58a06eb829da76ae193c77bb938bcfa153 1861 1834 2015-11-13T15:24:19Z Oliver 1 wikitext text/x-wiki Confirmation by examination and provisions of objective evidence that specified [[Requirement|requirements]] have been fulfilled. In design and development, verification concerns the process of examining the result of a given [[activity]] to determine conformity with the stated requirement for that activity. “Verified” is used to designate the corresponding status. [ISO 8402: 1994]<br /> According to ISO/IEC/IEEE 29119:<br /> Verification is confirmation, through the provision of objective evidence, that specified requirements have been fulfilled in a given work item. 6084b5e2fa30e5ce9f5a6b911ddfecfcbb47e7bb 0 288 1835 336 2015-11-13T14:59:38Z Oliver 1 wikitext text/x-wiki Existence of means in addition to the means that would be sufficient for an element to perform a required [[function]] or to represent information. Redundancy is used in ISO 26262 with respect to achieving a [[safety goal]], a specified [[Safety Requirement|safety requirement]], or representing safety-related information. 6319454e2b923cf3c89c3904b7ff47a386495bae 0 1047 1836 2015-11-13T15:02:16Z Oliver 1 Created page with "A property or capability that must be achieved or possessed by a system, system item, product, or service to satisfy a contract, standard, specification or other formally impo..." wikitext text/x-wiki A property or capability that must be achieved or possessed by a system, system item, product, or service to satisfy a contract, standard, specification or other formally imposed documents.<br /> = Functional Requirement = A statement that identifies what a product or process must accomplish to produce required behavior and/or results.<br /> (from ISO/IEC/IEEE 24765) = Non-Functional Requirement = a85fb0028a8fe05e806cd780f33f109966f07683 0 1037 1837 1820 2015-11-13T15:02:31Z Oliver 1 wikitext text/x-wiki [[Requirement#Functional Requirement|Functional Requirement]] 7290781b55d2b36845ed907120674de5bbed8f07 0 1048 1838 2015-11-13T15:04:10Z Oliver 1 Created page with "[[Requirement#Non-Functional Requirement|Non-Functional Requirement]]" wikitext text/x-wiki [[Requirement#Non-Functional Requirement|Non-Functional Requirement]] cf8ca0e14ab2d279eed90a664dba1587199d2512 0 1049 1839 2015-11-13T15:06:00Z Oliver 1 Created page with "A document that specifies the [[Requirement|requirements ]]for a system or item. Typically included are [[Functional requirement|functional requirements]], performance require..." wikitext text/x-wiki A document that specifies the [[Requirement|requirements ]]for a system or item. Typically included are [[Functional requirement|functional requirements]], performance requirements, interface requirements, design requirements, and development standards.<br /> (from [[Automotive SPICE]] V3.0) a0f9084eadbb095e3410b01619422d87ebc21feb 0 1050 1840 2015-11-13T15:06:25Z Oliver 1 Created page with "Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.<br /> (from ISO/IEC/IEEE 24765)" wikitext text/x-wiki Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.<br /> (from ISO/IEC/IEEE 24765) f08a7d27b163c351ecd19dd124aa901fb3e6eed5 1841 1840 2015-11-13T15:06:35Z Oliver 1 wikitext text/x-wiki Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.<br /> (from ISO/IEC/IEEE 24765) [[Category:Software]] 87de5a86e035c8452a19bab9f6d2764786391b7d 0 320 1842 1470 2015-11-13T15:07:50Z Oliver 1 wikitext text/x-wiki Software-Components (SW-C) are architectural [[element]]s that provide and/or require interfaces and are connected to each other through the [[Virtual Functional Bus]] to fulfill architectural responsibilities. The Software Component is the central structural element used when building a system at the VFB-level. A SW-C has well-defined [[port]]s, through which the component can interact with other Software Components. A Software Component has a formal description defined by the Software Component [[template]]. Software Components can be abbreviated as SW-Cs. A SW-C contains a [[Software Component Description]] (SWCD) and the [[Software Component Implementation|implementation]]. <br /> In Automotive SPICE V3.0 the term "software component" is used for the lowest level elements of the software architecture for which finally the detailed design is defined. A software "component" consists of one or more software "units". [[Category:AUTOSAR]] [[Category:Software]] bf60755e140c9f791f7a2cb2341d3dd3ff164095 0 1051 1843 2015-11-13T15:08:24Z Oliver 1 Created page with "Identifiable part of a software product.<br /> (from ISO/IEC/IEEE 24765) [[Category:Software]]" wikitext text/x-wiki Identifiable part of a software product.<br /> (from ISO/IEC/IEEE 24765) [[Category:Software]] c20c4919339e65a8c0fdd19e908bd8db30994a01 0 1052 1844 2015-11-13T15:11:58Z Oliver 1 Created page with "A software unit is a [[Software Component|software component]] that is not further subdivided.<br /> In case of [[AUTOSAR]] this would be a [[Runnable Entity]]. Category:Sof..." wikitext text/x-wiki A software unit is a [[Software Component|software component]] that is not further subdivided.<br /> In case of [[AUTOSAR]] this would be a [[Runnable Entity]]. [[Category:Software]] 05e64c738b3d0269be7d7c123cacc3dce10a49ac 0 1053 1845 2015-11-13T15:12:22Z Oliver 1 Created page with "A process of evaluating an item based on its form, structure, content, or documentation.<br /> (from [[Automotive SPICE]] V3.0)" wikitext text/x-wiki A process of evaluating an item based on its form, structure, content, or documentation.<br /> (from [[Automotive SPICE]] V3.0) 8c95a2a9e4088061ff30c6b7180f1a11ef7671cd 0 336 1846 392 2015-11-13T15:13:06Z Oliver 1 wikitext text/x-wiki An integrated composite that consists of one or more of the [[process]]es, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. <br /> According to [[Automotive SPICE]] V3.0:<br /> A collection of interacting [[Item|items ]]organized to accomplish a specific function or set of functions within a specific environment. 4fe067b85ac4335df4f80a4e83057e16cd374e43 1847 1846 2015-11-13T15:13:22Z Oliver 1 wikitext text/x-wiki An integrated composite that consists of one or more of the [[process]]es, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. <br /> According to [[Automotive SPICE]] V3.0:<br /> A collection of interacting [[Item|items]] organized to accomplish a specific function or set of functions within a specific environment. c79bca3ef5c4e2e99185cebf665865600f1b7301 0 1054 1848 2015-11-13T15:13:54Z Oliver 1 Created page with "Identifiable part of the [[System|system]].<br /> (from [[Automotive SPICE]] V3.0)" wikitext text/x-wiki Identifiable part of the [[System|system]].<br /> (from [[Automotive SPICE]] V3.0) f916eb13447ffd88ee25b5e3979809d29e9f371f 0 1055 1849 2015-11-13T15:14:30Z Oliver 1 Created page with "Testing conducted on a complete, integrated [[system]] to evaluate the system's compliance with its specified [[Requirement|requirements]].<br /> (from ISO/IEC/IEEE 24765)" wikitext text/x-wiki Testing conducted on a complete, integrated [[system]] to evaluate the system's compliance with its specified [[Requirement|requirements]].<br /> (from ISO/IEC/IEEE 24765) 127e6f800eed425ee058a4aaac6930079902001c 0 1024 1850 1804 2015-11-13T15:15:58Z Oliver 1 Redirected page to [[Testing#Acceptance Testing]] wikitext text/x-wiki #REDIRECT [[Testing#Acceptance Testing]] 702fd8f5397551fd8dfbb754ee96abf0ccff42ff 0 1028 1851 1831 2015-11-13T15:16:49Z Oliver 1 Redirected page to [[Testing#Black-box Testing]] wikitext text/x-wiki #REDIRECT [[Testing#Black-box Testing]] 6e82d68d53443922a3ae808a3bbe4198fbc0fc1d 0 1039 1852 1822 2015-11-13T15:17:36Z Oliver 1 Redirected page to [[Testing#Functional Testing]] wikitext text/x-wiki #REDIRECT [[Testing#Functional Testing]] eee7a0be9a8175ce1c4267e780a8763855d16ecd 0 1043 1853 1827 2015-11-13T15:18:25Z Oliver 1 Redirected page to [[Testing#Integration Testing]] wikitext text/x-wiki #REDIRECT [[Testing#Integration Testing]] c8d135f4567fc0d4491baee3ef0bc5166608f8d9 0 1046 1854 1830 2015-11-13T15:19:58Z Oliver 1 Redirected page to [[Testing#Regression Testing]] wikitext text/x-wiki #REDIRECT [[Testing#Regression Testing]] 265ab6222bdc152bda2585d6eea50cd7a9bb1044 0 1056 1855 2015-11-13T15:20:26Z Oliver 1 Created page with "Activity in which an [[item]] ([[system]], [[hardware]], or [[software]]) is executed under specific conditions; and the results are recorded, summarized and communicated.<br..." wikitext text/x-wiki Activity in which an [[item]] ([[system]], [[hardware]], or [[software]]) is executed under specific conditions; and the results are recorded, summarized and communicated.<br /> = Acceptance Testing = Formal testing conducted to enable a user, customer, or authorized entity to determine whether to accept a system or component.<br /> (from ISO/IEC/IEEE 24765) = Black-box Testing = Method of [[requirement]] testing where tests are developed without knowledge of the internal structure and mechanisms of the tested item.<br /> (from Automotive SPICE V3.0) = Functional Testing = Testing conducted to evaluate the compliance of a system or component with specified functional requirements.<br /> (from ISO/IEC/IEEE 24765) = Integration Testing = Testing in which items ([[Software item|software items]], [[Hardware item|hardware items]], or [[System item|system items]]) are combined and tested to evaluate the interaction among them.<br /> (from [[Automotive SPICE]] V3.0) = Regression Testing = Selective retesting of a system or item to verify that modifications have not caused unintended effects and that the system or item still complies with its specified requirements.<br /> (from [[Automotive SPICE]] V3.0) f05535a9045bc906ed301913005cea24d802125c 1859 1855 2015-11-13T15:22:45Z Oliver 1 wikitext text/x-wiki Activity in which an [[item]] ([[system]], [[hardware]], or [[software]]) is executed under specific conditions; and the results are recorded, summarized and communicated.<br /> = Acceptance Testing = Formal testing conducted to enable a user, customer, or authorized entity to determine whether to accept a system or component.<br /> (from ISO/IEC/IEEE 24765) = Black-box Testing = Method of [[requirement]] testing where tests are developed without knowledge of the internal structure and mechanisms of the tested item.<br /> (from Automotive SPICE V3.0) = Functional Testing = Testing conducted to evaluate the compliance of a system or component with specified functional requirements.<br /> (from ISO/IEC/IEEE 24765) = Integration Testing = Testing in which items ([[Software item|software items]], [[Hardware item|hardware items]], or [[System item|system items]]) are combined and tested to evaluate the interaction among them.<br /> (from [[Automotive SPICE]] V3.0) = Regression Testing = Selective retesting of a system or item to verify that modifications have not caused unintended effects and that the system or item still complies with its specified requirements.<br /> (from [[Automotive SPICE]] V3.0) = Unit Testing = The testing of individual [[Software unit|software units]] or a set of combined software units.<br /> (from [[Automotive SPICE]] V3.0) 718593c40c492a4f62b8954bf9afd78e11d1c507 1862 1859 2015-11-13T15:25:24Z Oliver 1 wikitext text/x-wiki Activity in which an [[item]] ([[system]], [[hardware]], or [[software]]) is executed under specific conditions; and the results are recorded, summarized and communicated.<br /> = Acceptance Testing = Formal testing conducted to enable a user, customer, or authorized entity to determine whether to accept a system or component.<br /> (from ISO/IEC/IEEE 24765) = Black-box Testing = Method of [[requirement]] testing where tests are developed without knowledge of the internal structure and mechanisms of the tested item.<br /> (from Automotive SPICE V3.0) = White-box Testing = Method of testing where tests are developed based on the knowledge of the internal structure and mechanisms of the tested item.<br /> (from Automotive SPICE V3.0) = Functional Testing = Testing conducted to evaluate the compliance of a system or component with specified functional requirements.<br /> (from ISO/IEC/IEEE 24765) = Integration Testing = Testing in which items ([[Software item|software items]], [[Hardware item|hardware items]], or [[System item|system items]]) are combined and tested to evaluate the interaction among them.<br /> (from [[Automotive SPICE]] V3.0) = Regression Testing = Selective retesting of a system or item to verify that modifications have not caused unintended effects and that the system or item still complies with its specified requirements.<br /> (from [[Automotive SPICE]] V3.0) = Unit Testing = The testing of individual [[Software unit|software units]] or a set of combined software units.<br /> (from [[Automotive SPICE]] V3.0) 484e11dc4e23add2e4c46fecb7ef2c4054b26b39 0 1032 1856 1812 2015-11-13T15:20:51Z Oliver 1 wikitext text/x-wiki Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional [[traceability]].<br /> (from [[Automotive SPICE]] V3.0) [[Category:Software]] 58b23b68ccc93ba9711d51d644d0c260f373b258 0 1057 1857 2015-11-13T15:21:20Z Oliver 1 Created page with "The degree to which a relationship can be established between two or more products of the [[development process]], especially products having a predecessor-successor or master..." wikitext text/x-wiki The degree to which a relationship can be established between two or more products of the [[development process]], especially products having a predecessor-successor or master-subordinate relationship to one another.<br /> (from ISO/IEC/IEEE 24765) 91f3fcca5bd1a295afb327aeb2c0fe41d9dadc55 0 1058 1858 2015-11-13T15:22:38Z Oliver 1 Redirected page to [[Testing#Unit Testing]] wikitext text/x-wiki #REDIRECT [[Testing#Unit Testing]] b450b45080e271fafe97531d59673ff96bd74b65 0 345 1860 403 2015-11-13T15:23:23Z Oliver 1 wikitext text/x-wiki Confirmation by examination and provisions of objective evidence that the particular requirements for a specific intended use are fulfilled. In design and development, validation concerns the process of examining a product to determine [[conformity]] with user needs. Validation is normally performed on the final product under defined operating conditions. It may be necessary in earlier stages. “Validated” is used to designate the corresponding status. Multiple validations may be carried out if there are different intended uses. [ISO 8402: 1994] <br /> According to ISO/IEC/IEEE 29119:<br /> Validation demonstrates that the work item can be used by the users for their specific tasks. a5ab75a62aaa85234b20270ba6767c411defd85a 0 1059 1863 2015-11-13T15:25:32Z Oliver 1 Redirected page to [[Testing#White-box Testing]] wikitext text/x-wiki #REDIRECT [[Testing#White-box Testing]] ee319c2914051d739b91f24472ece01540e9a10d 0 1060 1864 2015-11-16T09:39:31Z Oliver 1 Redirected page to [[Definition of Done]] wikitext text/x-wiki #REDIRECT [[Definition of Done]] [[Category:Software]] d818428f6d72f82f75d9a56a52f0b752c9c98194 0 1061 1865 2015-11-19T10:15:17Z Oliver 1 Redirected page to [[Capability Maturity Model Integration]] wikitext text/x-wiki #REDIRECT [[Capability Maturity Model Integration]] 29ef884b7363ff594d9def4e16a73a784df10d89 0 1062 1866 2015-11-19T10:15:41Z Oliver 1 Redirected page to [[Component Off The Shelf]] wikitext text/x-wiki #REDIRECT [[Component Off The Shelf]] 7d64276a53459075f286d8d32e8e836b254cf9e1 0 1063 1867 2015-11-19T10:15:59Z Oliver 1 Redirected page to [[Change Request Board]] wikitext text/x-wiki #REDIRECT [[Change Request Board]] b118286cc72c3347a2afbaad4996b7aab1481538 0 1064 1868 2015-11-19T10:16:25Z Oliver 1 Redirected page to [[European Foundation for Quality Management]] wikitext text/x-wiki #REDIRECT [[European Foundation for Quality Management]] 5b8a52d61d6f57a1e94b8ea71ccb0e77f71507e3 0 1065 1869 2015-11-19T10:17:55Z Oliver 1 Created page with "#REDIRECT [http://www.efqm.org/]" wikitext text/x-wiki #REDIRECT [http://www.efqm.org/] 5898b4eb3d8a195361cda09127db2907d1955028 0 1066 1870 2015-11-19T10:18:16Z Oliver 1 Created page with "Entry Criteria, Inputs, Tasks, Verification, Outputs, eXit Criteria" wikitext text/x-wiki Entry Criteria, Inputs, Tasks, Verification, Outputs, eXit Criteria 37e3694a38998edd63b9d327150e664406cd1190 0 1067 1871 2015-11-19T10:19:15Z Oliver 1 Redirected page to [[wikipedia:Event tree analysis]] wikitext text/x-wiki #REDIRECT [[wikipedia:Event_tree_analysis|Event Tree Analysis]] 0b940e4e431c8023b41aec931c3be3946b6e2fda 0 1068 1872 2015-11-19T10:20:25Z Oliver 1 Redirected page to [[wikipedia:Failure mode and effects analysis]] wikitext text/x-wiki #REDIRECT [[wikipedia:Failure_mode_and_effects_analysis|Failure mode and effects analysis]] 4946d7c236ed74fefa318e0e8e12722d9c8760b4 0 859 1873 1321 2015-11-19T10:21:33Z Oliver 1 Redirected page to [[Fault Tree Analysis]] wikitext text/x-wiki #REDIRECT [[Fault Tree Analysis]] f109b26b780dcfeab849042d1e08c0d28f3dc927 0 1069 1874 2015-11-19T10:21:53Z Oliver 1 Redirected page to [[wikipedia:Fault tree analysis]] wikitext text/x-wiki #REDIRECT [[wikipedia:Fault_tree_analysis|Fault Tree Analysis]] c64c44f441a1bed1cc2108492eef11599a2f167e 0 1070 1875 2015-11-19T10:22:19Z Oliver 1 Created page with "Good Automated Manufacturing Practice" wikitext text/x-wiki Good Automated Manufacturing Practice f456343355092f433013c8caa915653e0bb782f9 0 1071 1876 2015-11-19T10:23:09Z Oliver 1 Created page with "Goal Question Metric" wikitext text/x-wiki Goal Question Metric 5629df3615854349794bed6a6d0b0a9f1a729618 0 1072 1877 2015-11-19T10:23:25Z Oliver 1 Created page with "Generic work product" wikitext text/x-wiki Generic work product 39af42ff9601ed7cbac0c0828acb905e5d956205 0 1073 1878 2015-11-19T10:23:46Z Oliver 1 Redirected page to [[Hazard and Operability Study]] wikitext text/x-wiki #REDIRECT [[Hazard and Operability Study]] 216cf6036582dae90a4d5ccb97c5f9f2772b9ba0 0 1074 1879 2015-11-19T13:33:13Z Oliver 1 Created page with "A list of open items (To-Do list), also known as OIL, LOP (list of open points), OPL (open points list)." wikitext text/x-wiki A list of open items (To-Do list), also known as OIL, LOP (list of open points), OPL (open points list). b4edd60e07dcd0dd75095cd6284b0149337fc851 0 1075 1880 2015-11-19T13:33:25Z Oliver 1 Redirected page to [[Open Issue List]] wikitext text/x-wiki #REDIRECT [[Open Issue List]] 6f191b35a0549fa2e84f8b2164625ff294be6ce6 0 1076 1881 2015-11-19T13:34:05Z Oliver 1 Redirected page to [[Open Issue List]] wikitext text/x-wiki #REDIRECT [[Open Issue List]] 6f191b35a0549fa2e84f8b2164625ff294be6ce6 0 1077 1882 2015-11-20T10:03:49Z Oliver 1 Redirected page to [[Emergency Change Advisory Board]] wikitext text/x-wiki #REDIRECT [[Emergency Change Advisory Board]] 57321a25d8d1fc7f6f69008ae9c98c88f3d485b5 0 791 1883 1245 2015-11-25T08:41:42Z Oliver 1 wikitext text/x-wiki = A-sample = = B-sample = = C-sample = = D-sample = Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] be3140aa33378f68a8458aa1486e3cdf3868d38c 0 1078 1884 2015-11-25T08:44:24Z Oliver 1 Redirected page to [[Hardware sample#A-sample]] wikitext text/x-wiki #REDIRECT [[Hardware sample#A-sample]] ee264326fe7ff148d46f7441f30bd0222ae14113 0 1079 1885 2015-11-25T08:44:38Z Oliver 1 Redirected page to [[Hardware sample#B-sample]] wikitext text/x-wiki #REDIRECT [[Hardware sample#B-sample]] 200bd80ad79d4a11792188bd3e362ec444b4079f 0 1080 1886 2015-11-25T08:46:36Z Oliver 1 Redirected page to [[Hardware sample#C-sample]] wikitext text/x-wiki #REDIRECT [[Hardware sample#C-sample]] 67c44dde3d2d4fa56f72ad7beb18dc0f0140f574 0 1081 1887 2015-11-25T08:47:39Z Oliver 1 Redirected page to [[Hardware sample#D-sample]] wikitext text/x-wiki #REDIRECT [[Hardware sample#D-sample]] b1fe461183c47609d2162c518167d9ffa5513eb3 0 1082 1888 2015-11-26T09:54:12Z Oliver 1 Redirected page to [[wikipedia:Software test documentation]] wikitext text/x-wiki #REDIRECT [[wikipedia:Software_test_documentation|Software Test Dokumentation]] 92995fb254b70b5ce99e51489313bb413d5498c5 0 1083 1889 2015-11-26T09:56:30Z Oliver 1 Redirected page to [[wikipedia:Software quality assurance]] wikitext text/x-wiki #REDIRECT [[wikipedia:Software_quality_assurance|Software Quality Assurance]] 988e00147f87f5fffe060b61db117308d4b201cf 0 1084 1890 2015-11-26T12:59:49Z Oliver 1 Redirected page to [[wikipedia:Software quality assurance]] wikitext text/x-wiki #REDIRECT [[wikipedia:Software_quality_assurance|Software Quality Assurance]] 988e00147f87f5fffe060b61db117308d4b201cf 0 1085 1891 2015-11-26T13:01:44Z Oliver 1 Redirected page to [[wikipedia:Software configuration management]] wikitext text/x-wiki #REDIRECT [[wikipedia:Software_configuration_management|Software Configuration Management]] af2835ea299e302d9d8e1f84aea855f333c270aa 0 1086 1892 2015-11-26T13:02:49Z Oliver 1 Redirected page to [[wikipedia:Software configuration management]] wikitext text/x-wiki #REDIRECT [[wikipedia:Software_configuration_management|Software Configuration Management Plan]] e557de66b01577732e790e6cdb23cf32262e06de 0 425 1893 1591 2015-11-26T13:04:28Z Oliver 1 wikitext text/x-wiki * [[wikipedia:Software_requirements_specification|Software Requirement Specification]] * [[Safety Restraint System]] 5c32c0ed9e08427bc836faa5aff00ef646931190 0 1087 1894 2015-11-26T13:05:08Z Oliver 1 Redirected page to [[wikipedia:Software design description]] wikitext text/x-wiki #REDIRECT [[wikipedia:Software_design_description|Software Design Description]] e0c973cfee86c23c86d02b85665f364c48328be7 0 1088 1895 2015-11-26T13:06:20Z Oliver 1 Redirected page to [[wikipedia:Software project management]] wikitext text/x-wiki #REDIRECT [[wikipedia:Software_project_management|Software Project Management]] fa1da89bc676eb647568187d8ec7ed11e28afe73 0 1089 1896 2015-11-26T13:06:34Z Oliver 1 Redirected page to [[wikipedia:Software project management]] wikitext text/x-wiki #REDIRECT [[wikipedia:Software_project_management|Software Project Management Plan]] f531255fa32e724ca84188e7b709636067f3f80f 0 89 1897 1692 2015-11-26T13:07:34Z Oliver 1 wikitext text/x-wiki * [[Transport Protocol]] * [[wikipedia:Test_plan|Test Plan]] 6b12ff79a94b2d7b554b52f5328837b7f5902aaf 0 1036 1898 1819 2015-11-27T08:36:36Z Oliver 1 wikitext text/x-wiki Fault (Fehlerursache) => Error (Fehler) => Failure (Fehlverhalten) = Fault = Abnormal condition (or defect) that can cause an [[element]] or an [[item]] to fail.<br /> Note that according to ISO/IEC/IEEE 24765 a Fault is a "A manifestation of an error in software.", which would be a failure in the definition of this wiki.<br /> in German: Fehlerursache = Error = Discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition. An error can arise as a result of unforeseen operating conditions or due to a [[fault]] within the system, [[subsystem]] or [[component]] being considered. A fault can manifest itself as an error within the considered [[element]] and, at the end of its latency, the error can cause a [[failure]]. As errors are faults that have been activated and propagated, a single error can (theoretically) have many possible root causes, i.e., faults.<br /> in German: Fehler = Failure (Defect) = Termination of the ability of an [[element]] or an [[item]] to perform a function as required. Termination is a reduction in, or loss of, ability of an element or an item to perform a function as required. There is a difference between “to perform a function as required” (stronger definition, use-oriented) and ”to perform a function as specified”, so a failure can result from an incorrect specification.<br /> in German: Fehlverhalten f8721d95ff5f090a1af5d16b8c30e5fc977c5bfd 0 1090 1899 2015-11-27T08:38:18Z Oliver 1 Created page with "Development method to achieve stability by succeeding repetition of development tasks in equal time frames." wikitext text/x-wiki Development method to achieve stability by succeeding repetition of development tasks in equal time frames. 39e8d18868cec2a396eaa72f45677300488099ff 0 333 1900 388 2015-11-27T08:38:37Z Oliver 1 wikitext text/x-wiki Systematic [[iteration]] of a reduced [[full-set assessment]] as a basis for maintaining the validity of the full-set assessment. Within AUTOSAR context, reduced set surveillances of the accredited party are scheduled yearly between the full-set assessments. 8078343786484bae321e38a1c189d6741b79c0db 0 1091 1901 2015-11-27T08:40:17Z Oliver 1 Redirected page to [[wikipedia:Peer review]] wikitext text/x-wiki #REDIRECT [[wikipedia:Peer_review|Peer Review]] 9a8d8dbbd955f0a631823528e1318f24fb240574 0 1092 1902 2015-11-27T08:41:05Z Oliver 1 Redirected page to [[wikipedia:Statement of work]] wikitext text/x-wiki #REDIRECT [[wikipedia:Statement_of_work|Statement of Work]] 1da81e441dcc8dd2973b7bfd4c18df4fb637b936 0 1093 1903 2015-11-27T09:26:59Z Oliver 1 Created page with "Software Development Plan in [[wikipedia:Software_project_management|IEEE 1058]]" wikitext text/x-wiki Software Development Plan in [[wikipedia:Software_project_management|IEEE 1058]] b20fce076d6ea4e1c22eed4ae945b6731f12ea29 0 607 1904 888 2015-12-02T15:12:23Z Oliver 1 wikitext text/x-wiki Das Produktionsteil-Freigabeverfahren (Production Part Approval Process - PPAP, deutsch: Erstmuster-Prüfbericht -EMPB) [http://www.qualitaetsmanagement.me/PPAP.htm] ist ein Bemusterungsverfahren für Hardware(komponenten) im Automobilbereich. Parallel dazu gibt es noch das Produktionsprozess- und Produktfreigabe Verfahren (PPF-Verfahren).<br /> see [[Hardware sample|D-Sample]]. 86cae6fde97b7f882a5d300b557f05112a3a1032 1906 1904 2015-12-02T15:12:47Z Oliver 1 wikitext text/x-wiki Das Produktionsteil-Freigabeverfahren (Production Part Approval Process - PPAP, deutsch: Erstmuster-Prüfbericht -EMPB) [http://www.qualitaetsmanagement.me/PPAP.htm] ist ein Bemusterungsverfahren für Hardware(komponenten) im Automobilbereich. Parallel dazu gibt es noch das Produktionsprozess- und Produktfreigabe Verfahren (PPF-Verfahren).<br /> see [[Hardware sample|D-Sample]]. [[Category:Hardware]] e0617c1565f1af0686187e9e433a084f71f47d36 0 802 1905 1246 2015-12-02T15:12:34Z Oliver 1 Redirected page to [[Production Part Approval Process]] wikitext text/x-wiki #REDIRECT [[Production Part Approval Process]] 422e6209857ab1264bcbaee6ba709cd6244962ba 8 1094 1907 2015-12-08T21:46:08Z Oliver 1 Created page with "*nt-wiki|Main_Page|automotive wiki *nt-blog|http://automotive.wiki/index.php?action=blog|Blog *Imprint|Imprint|Imprint *Privacy|Privacy|Privacy" wikitext text/x-wiki *nt-wiki|Main_Page|automotive wiki *nt-blog|http://automotive.wiki/index.php?action=blog|Blog *Imprint|Imprint|Imprint *Privacy|Privacy|Privacy ac7ace05be7dd1edcb55f75b72ec04a0bbca6643 1908 1907 2015-12-09T08:43:39Z Oliver 1 wikitext text/x-wiki *nt-wiki|Main_Page|automotive wiki *Imprint|Imprint|Imprint *Privacy|Privacy|Privacy 6989b0171e08cd1ad5378e0edef4313357f064a5 0 1066 1909 1870 2015-12-10T13:26:33Z Oliver 1 wikitext text/x-wiki Entry Criteria, Inputs, Tasks, Verification, Outputs, eXit Criteria EITVOX Model<br />Software Engineering, An Industrial Approach<br />Prentice Hall, Englewood Cliffs, New Jersey, 1988<br />Radice, Ronald A., Phillips, Richard W. 272b094e69ebb357788703d5c5e228e078e61a6a 0 1095 1910 2015-12-10T16:27:20Z Oliver 1 Created page with "<div class="flex_column av_one_full flex_column_div av-zero-column-padding first avia-builder-el-2 el_before_av_one_full avia-builder-el-first "><div class="av-special-he..." wikitext text/x-wiki <div class="flex_column av_one_full flex_column_div av-zero-column-padding first avia-builder-el-2 el_before_av_one_full avia-builder-el-first "><div class="av-special-heading av-special-heading-h2 blockquote modern-quote avia-builder-el-3 avia-builder-el-no-sibling "> ==Imprint== </div> </div> <div class="flex_column av_one_full flex_column_div av-zero-column-padding first avia-builder-el-4 el_after_av_one_full avia-builder-el-last column-top-margin"><section class="av_textblock_section"><div class="avia_textblock " itemprop="text"> ==='''Legal Disclosure'''=== Information in accordance with section 5 TMG '''SCHEID automotive GmbH'''<br />Obermühlteich 12<br />76646 Bruchsal '''Contact'''<br />Phone: +49 151 56977406<br />E-Mail: [mailto:info@SCHEID-automotive.com info@SCHEID-automotive.com]<br />Website: [http://www.scheid-automotive.com/ www.SCHEID-automotive.com] Geschäftsführer / Managing Director: Oliver Scheid<br />Sitz der Gesellschaft / registered office: Bruchsal<br />Registergericht / Register Court: Amtsgericht Mannheim HRB 713257.<br />Steuernummer USt-IdNr. / VAT No.: DE 280101340 '''Person responsible for content in accordance with 55 Abs. 2 RStV'''<br />Oliver Scheid ==='''Disclaimer'''=== '''Accountability for content'''<br />The contents of our pages have been created with the utmost care. However, we cannot guarantee the contents’ accuracy, completeness or topicality. According to statutory provisions, we are furthermore responsible for our own content on these web pages. In this context, please note that we are accordingly not obliged to monitor merely the transmitted or saved information of third parties, or investigate circumstances pointing to illegal activity. Our obligations to remove or block the use of information under generally applicable laws remain unaffected by this as per §§ 8 to 10 of the Telemedia Act (TMG). '''Accountability for links'''<br />Responsibility for the content of external links (to web pages of third parties) lies solely with the operators of the linked pages. No violations were evident to us at the time of linking. Should any legal infringement become known to us, we will remove the respective link immediately. '''Copyright'''<br />Our web pages and their contents are subject to German copyright law. Unless expressly permitted by law (§ 44a et seq. of the copyright law), every form of utilizing, reproducing or processing works subject to copyright protection on our web pages requires the prior consent of the respective owner of the rights. Individual reproductions of a work are allowed only for private use, so must not serve either directly or indirectly for earnings. Unauthorized utilization of copyrighted works is punishable (§ 106 of the copyright law). </div> </section></div> 53044a7509c00250c9882b2f5981798d86717c8b 1911 1910 2015-12-10T16:35:50Z Oliver 1 wikitext text/x-wiki ==='''Legal Disclosure'''=== Information in accordance with section 5 TMG '''SCHEID automotive GmbH'''<br />Obermühlteich 12<br />76646 Bruchsal '''Contact'''<br />Phone: +49 151 56977406<br />E-Mail: [mailto:info@SCHEID-automotive.com info@SCHEID-automotive.com]<br />Website: [http://www.scheid-automotive.com/ www.SCHEID-automotive.com] Geschäftsführer / Managing Director: Oliver Scheid<br />Sitz der Gesellschaft / registered office: Bruchsal<br />Registergericht / Register Court: Amtsgericht Mannheim HRB 713257.<br />Steuernummer USt-IdNr. / VAT No.: DE 280101340 '''Person responsible for content in accordance with 55 Abs. 2 RStV'''<br />Oliver Scheid ==='''Disclaimer'''=== '''Accountability for content'''<br />The contents of our pages have been created with the utmost care. However, we cannot guarantee the contents’ accuracy, completeness or topicality. According to statutory provisions, we are furthermore responsible for our own content on these web pages. In this context, please note that we are accordingly not obliged to monitor merely the transmitted or saved information of third parties, or investigate circumstances pointing to illegal activity. Our obligations to remove or block the use of information under generally applicable laws remain unaffected by this as per §§ 8 to 10 of the Telemedia Act (TMG). '''Accountability for links'''<br />Responsibility for the content of external links (to web pages of third parties) lies solely with the operators of the linked pages. No violations were evident to us at the time of linking. Should any legal infringement become known to us, we will remove the respective link immediately. '''Copyright'''<br />Our web pages and their contents are subject to German copyright law. Unless expressly permitted by law (§ 44a et seq. of the copyright law), every form of utilizing, reproducing or processing works subject to copyright protection on our web pages requires the prior consent of the respective owner of the rights. Individual reproductions of a work are allowed only for private use, so must not serve either directly or indirectly for earnings. Unauthorized utilization of copyrighted works is punishable (§ 106 of the copyright law). 480193f2d2f328ffd772801e462f0cf28c499967 1914 1911 2015-12-10T21:47:22Z Oliver 1 wikitext text/x-wiki '''Privacy Statement''' '''General''' Your personal data (e.g. title, name, house address, e-mail address, phone number, bank details, credit card number) are processed by us only in accordance with the provisions of German data privacy laws. The following provisions describe the type, scope and purpose of collecting, processing and utilizing personal data. This data privacy policy applies only to our web pages. If links on our pages route you to other pages, please inquire there on how your data are handled in such cases. '''Inventory data''' (1) Your personal data, insofar as these are necessary for this contractual relationship (inventory data) in terms of its establishment, organization of content and modifications, are used exclusively for fulfilling the contract. For goods to be delivered, for instance, your name and address must be relayed to the supplier of the goods.<br />(2) Without your explicit consent or a legal basis, your personal data are not passed on to third parties outside the scope of fulfilling this contract. After completion of the contract, your data are blocked against further use. After expiry of deadlines as per tax-related and commercial regulations, these data are deleted unless you have expressly consented to their further use. '''Social plug-ins from Twitter''' With Twitter and its Retweet functions, we use social plug-ins from Twitter.com, operated by Twitter Inc. 795 Folsom St., Suite 600, San Francisco, CA 94107. If you use Retweet, the websites visited by you are announced to third parties and associated with your Twitter account. Details about handling of your data by Twitter as well as your rights and setting options for protecting your personal information can be found in Twitter’s data privacy policy: [http://twitter.com/privacy http://twitter.com/privacy] '''Piwik''' '''This website uses '''[http://piwik.org/ Piwik], a web analytics open-source software. Piwik uses “cookies”, which are text files placed on your computer, to help the website analyze how users use the site. The information generated by the cookie about your use of the website (including your IP address anonymized prior to its storage) will be stored on the server of the service provider in Germany. You may refuse the use of cookies by selecting the appropriate settings on your browser, however please note that if you do this you may not be able to use the full functionality of this website. {{#widget:Iframe|url=http://piwik.automotive.wiki/index.php?module=CoreAdminHome&action=optOut&language=en|width=600|height=200|border=0}} '''Disclosure''' According to the German Federal Data Protection Act, you have a right to free-of-charge information about your stored data, and possibly entitlement to correction, blocking or deletion of such data. Inquiries can be directed to the following e-mail addresses: ( [mailto:info@scheid-automotive.com info@scheid-automotive.com] ) ff998a2512057e357648f2d7d09b467c2a225adc 1916 1914 2015-12-11T12:05:24Z Oliver 1 wikitext text/x-wiki '''Privacy Statement''' '''General''' Your personal data (e.g. title, name, house address, e-mail address, phone number, bank details, credit card number) are processed by us only in accordance with the provisions of German data privacy laws. The following provisions describe the type, scope and purpose of collecting, processing and utilizing personal data. This data privacy policy applies only to our web pages. If links on our pages route you to other pages, please inquire there on how your data are handled in such cases. '''Inventory data''' (1) Your personal data, insofar as these are necessary for this contractual relationship (inventory data) in terms of its establishment, organization of content and modifications, are used exclusively for fulfilling the contract. For goods to be delivered, for instance, your name and address must be relayed to the supplier of the goods.<br />(2) Without your explicit consent or a legal basis, your personal data are not passed on to third parties outside the scope of fulfilling this contract. After completion of the contract, your data are blocked against further use. After expiry of deadlines as per tax-related and commercial regulations, these data are deleted unless you have expressly consented to their further use. '''Social plug-ins from Twitter''' With Twitter and its Retweet functions, we use social plug-ins from Twitter.com, operated by Twitter Inc. 795 Folsom St., Suite 600, San Francisco, CA 94107. If you use Retweet, the websites visited by you are announced to third parties and associated with your Twitter account. Details about handling of your data by Twitter as well as your rights and setting options for protecting your personal information can be found in Twitter’s data privacy policy: [http://twitter.com/privacy http://twitter.com/privacy] '''Piwik''' '''This website uses '''[http://piwik.org/ Piwik], a web analytics open-source software. Piwik uses “cookies”, which are text files placed on your computer, to help the website analyze how users use the site. The information generated by the cookie about your use of the website (including your IP address anonymized prior to its storage) will be stored on the server of the service provider in Germany. You may refuse the use of cookies by selecting the appropriate settings on your browser, however please note that if you do this you may not be able to use the full functionality of this website. '''Disclosure''' According to the German Federal Data Protection Act, you have a right to free-of-charge information about your stored data, and possibly entitlement to correction, blocking or deletion of such data. Inquiries can be directed to the following e-mail addresses: ( [mailto:info@scheid-automotive.com info@scheid-automotive.com] ) 0bb5b0b427a6de927948b0ffcba0fd5e3c7c3bb8 1930 1916 2016-01-11T21:26:14Z Oliver 1 wikitext text/x-wiki ==='''Legal Disclosure'''=== Information in accordance with section 5 TMG '''SCHEID automotive GmbH'''<br />Obermühlteich 12<br />76646 Bruchsal '''Contact'''<br />Phone: +49 151 56977406<br />E-Mail: [mailto:info@SCHEID-automotive.com info@SCHEID-automotive.com]<br />Website: [http://www.scheid-automotive.com/ www.SCHEID-automotive.com] Geschäftsführer / Managing Director: Oliver Scheid<br />Sitz der Gesellschaft / registered office: Bruchsal<br />Registergericht / Register Court: Amtsgericht Mannheim HRB 713257.<br />Steuernummer USt-IdNr. / VAT No.: DE 280101340 '''Person responsible for content in accordance with 55 Abs. 2 RStV'''<br />Oliver Scheid ==='''Disclaimer'''=== '''Accountability for content'''<br />The contents of our pages have been created with the utmost care. However, we cannot guarantee the contents’ accuracy, completeness or topicality. According to statutory provisions, we are furthermore responsible for our own content on these web pages. In this context, please note that we are accordingly not obliged to monitor merely the transmitted or saved information of third parties, or investigate circumstances pointing to illegal activity. Our obligations to remove or block the use of information under generally applicable laws remain unaffected by this as per §§ 8 to 10 of the Telemedia Act (TMG). '''Accountability for links'''<br />Responsibility for the content of external links (to web pages of third parties) lies solely with the operators of the linked pages. No violations were evident to us at the time of linking. Should any legal infringement become known to us, we will remove the respective link immediately. '''Copyright'''<br />Our web pages and their contents are subject to German copyright law. Unless expressly permitted by law (§ 44a et seq. of the copyright law), every form of utilizing, reproducing or processing works subject to copyright protection on our web pages requires the prior consent of the respective owner of the rights. Individual reproductions of a work are allowed only for private use, so must not serve either directly or indirectly for earnings. Unauthorized utilization of copyrighted works is punishable (§ 106 of the copyright law). 480193f2d2f328ffd772801e462f0cf28c499967 0 1096 1912 2015-12-10T16:45:28Z Oliver 1 Created page with "'''Privacy Statement<br />''' '''General''' Your personal data (e.g. title, name, house address, e-mail address, phone number, bank details, credit card number) are processe..." wikitext text/x-wiki '''Privacy Statement<br />''' '''General''' Your personal data (e.g. title, name, house address, e-mail address, phone number, bank details, credit card number) are processed by us only in accordance with the provisions of German data privacy laws. The following provisions describe the type, scope and purpose of collecting, processing and utilizing personal data. This data privacy policy applies only to our web pages. If links on our pages route you to other pages, please inquire there on how your data are handled in such cases. '''Inventory data''' (1) Your personal data, insofar as these are necessary for this contractual relationship (inventory data) in terms of its establishment, organization of content and modifications, are used exclusively for fulfilling the contract. For goods to be delivered, for instance, your name and address must be relayed to the supplier of the goods.<br />(2) Without your explicit consent or a legal basis, your personal data are not passed on to third parties outside the scope of fulfilling this contract. After completion of the contract, your data are blocked against further use. After expiry of deadlines as per tax-related and commercial regulations, these data are deleted unless you have expressly consented to their further use. '''Social plug-ins from Twitter''' With Twitter and its Retweet functions, we use social plug-ins from Twitter.com, operated by Twitter Inc. 795 Folsom St., Suite 600, San Francisco, CA 94107. If you use Retweet, the websites visited by you are announced to third parties and associated with your Twitter account. Details about handling of your data by Twitter as well as your rights and setting options for protecting your personal information can be found in Twitter’s data privacy policy: [http://twitter.com/privacy http://twitter.com/privacy] '''Piwik''' '''This website uses '''[http://piwik.org/ Piwik], a web analytics open-source software. Piwik uses “cookies”, which are text files placed on your computer, to help the website analyze how users use the site. The information generated by the cookie about your use of the website (including your IP address anonymized prior to its storage) will be stored on the server of the service provider in Germany. You may refuse the use of cookies by selecting the appropriate settings on your browser, however please note that if you do this you may not be able to use the full functionality of this website. {{#widget:Iframe|url=http://piwik.automotive.wiki/index.php?module=CoreAdminHome&action=optOut&language=en|width=200|height=600|border=0}} '''Disclosure''' According to the German Federal Data Protection Act, you have a right to free-of-charge information about your stored data, and possibly entitlement to correction, blocking or deletion of such data. Inquiries can be directed to the following e-mail addresses: ( [mailto:info@scheid-automotive.com info@scheid-automotive.com] ) 1489f90a00f35cd42603054d67d82615c7e791c4 1915 1912 2015-12-11T12:03:15Z Oliver 1 wikitext text/x-wiki Privacy''' Statement<br />''' '''General''' Your personal data (e.g. title, name, house address, e-mail address, phone number, bank details, credit card number) are processed by us only in accordance with the provisions of German data privacy laws. The following provisions describe the type, scope and purpose of collecting, processing and utilizing personal data. This data privacy policy applies only to our web pages. If links on our pages route you to other pages, please inquire there on how your data are handled in such cases. '''Inventory data''' (1) Your personal data, insofar as these are necessary for this contractual relationship (inventory data) in terms of its establishment, organization of content and modifications, are used exclusively for fulfilling the contract. For goods to be delivered, for instance, your name and address must be relayed to the supplier of the goods.<br />(2) Without your explicit consent or a legal basis, your personal data are not passed on to third parties outside the scope of fulfilling this contract. After completion of the contract, your data are blocked against further use. After expiry of deadlines as per tax-related and commercial regulations, these data are deleted unless you have expressly consented to their further use. '''Social plug-ins from Twitter''' With Twitter and its Retweet functions, we use social plug-ins from Twitter.com, operated by Twitter Inc. 795 Folsom St., Suite 600, San Francisco, CA 94107. If you use Retweet, the websites visited by you are announced to third parties and associated with your Twitter account. Details about handling of your data by Twitter as well as your rights and setting options for protecting your personal information can be found in Twitter’s data privacy policy: [http://twitter.com/privacy http://twitter.com/privacy] '''Piwik''' '''This website uses '''[http://piwik.org/ Piwik], a web analytics open-source software. Piwik uses “cookies”, which are text files placed on your computer, to help the website analyze how users use the site. The information generated by the cookie about your use of the website (including your IP address anonymized prior to its storage) will be stored on the server of the service provider in Germany. You may refuse the use of cookies by selecting the appropriate settings on your browser, however please note that if you do this you may not be able to use the full functionality of this website. {{#widget:Iframe|url=http://piwik.automotive.wiki/index.php?module=CoreAdminHome&action=optOut&language=en|width=900|height=200|border=0}} '''Disclosure''' According to the German Federal Data Protection Act, you have a right to free-of-charge information about your stored data, and possibly entitlement to correction, blocking or deletion of such data. Inquiries can be directed to the following e-mail addresses: ( [mailto:info@scheid-automotive.com info@scheid-automotive.com] ) 96e32ef530208ac49e30c6ae4e9971c2f6738f4e 274 1097 1913 2015-12-10T21:45:47Z Oliver 1 Created page with "<noinclude>__NOTOC__ This widget allows you to embed any web page on your wiki page using an iframe tag. Created by [http://www.mediawikiwidgets.org/User:Sergey_Chernyshev Se..." wikitext text/x-wiki <noinclude>__NOTOC__ This widget allows you to embed any web page on your wiki page using an iframe tag. Created by [http://www.mediawikiwidgets.org/User:Sergey_Chernyshev Sergey Chernyshev] == Using this widget == For information on how to use this widget, see [http://www.mediawikiwidgets.org/Iframe widget description page on MediaWikiWidgets.org]. <big>'''<font color="red">This widget shouldn't be used on a publicly-editable wiki.</font>'''</big> While the url is validated to be a valid url, there is no way the widget can check the contents of the page that is included. When enabling this widget, you allow any user that can edit to include any page, including malicious pages (containing trojans, backdoors, viruses etc), pages that brake out of the iframe and pages that look like your site, but actually is a copy used for phishing. == Copy to your site == To use this widget on your site, just install [http://www.mediawiki.org/wiki/Extension:Widgets MediaWiki Widgets extension] and copy [{{fullurl:{{FULLPAGENAME}}|action=edit}} full source code] of this page to your wiki as '''{{FULLPAGENAME}}''' article. </noinclude><includeonly><iframe src="<!--{$url|validate:url}-->" frameborder="<!--{$border|validate:int|default:0}-->" width="<!--{$width|escape:html|default:400}-->" height="<!--{$height|escape:html|default:300}-->"></iframe></includeonly> b9e730bb82a6b61e371dba3201c8d743c5a46e46 0 1073 1917 1878 2015-12-15T07:56:30Z Oliver 1 Redirected page to [[wikipedia:Hazard and operability study]] wikitext text/x-wiki #REDIRECT [[wikipedia:Hazard_and_operability_study|Hazard and operability study]] 7e695d9da1677e2b29bdfbbab2cf1e1d9d8d34bf 0 1098 1918 2015-12-15T07:57:42Z Oliver 1 Created page with "PAAG is German for Prognose, Auffinden der Ursache, Abschätzen der Auswirkungen, Gegenmaßnahmen.<br /> See wikipedia:Hazard_and_operability_study|Hazard and operability..." wikitext text/x-wiki PAAG is German for Prognose, Auffinden der Ursache, Abschätzen der Auswirkungen, Gegenmaßnahmen.<br /> See [[wikipedia:Hazard_and_operability_study|Hazard and operability study]] 324508af501a3e1e43c0836b6408c3ad178e860b 0 1099 1919 2016-01-04T11:25:11Z Oliver 1 Redirected page to [[AutosarDataType#Application Data Level (ApplicationDataType)]] wikitext text/x-wiki #REDIRECT [[AutosarDataType#Application Data Level (ApplicationDataType)]] 188c180ca8f32edbe340e814448134e59d713cc6 0 1100 1920 2016-01-04T11:26:19Z Oliver 1 Redirected page to [[AutosarDataType#Application Data Level (ApplicationDataType)]] wikitext text/x-wiki #REDIRECT [[AutosarDataType#Application Data Level (ApplicationDataType)]] 188c180ca8f32edbe340e814448134e59d713cc6 0 1101 1921 2016-01-04T11:27:18Z Oliver 1 Redirected page to [[AutosarDataType#Application Primitive Data Types (ApplicationPrimitiveDataType)]] wikitext text/x-wiki #REDIRECT [[AutosarDataType#Application Primitive Data Types (ApplicationPrimitiveDataType)]] cb67a18cc263bbedf0ee60cfcf8fe8e07ffafcdb 0 1102 1922 2016-01-04T11:27:39Z Oliver 1 Redirected page to [[AutosarDataType#Application Primitive Data Types (ApplicationPrimitiveDataType)]] wikitext text/x-wiki #REDIRECT [[AutosarDataType#Application Primitive Data Types (ApplicationPrimitiveDataType)]] cb67a18cc263bbedf0ee60cfcf8fe8e07ffafcdb 0 1103 1923 2016-01-04T11:28:21Z Oliver 1 Redirected page to [[AutosarDataType#Application Composite Data Type (ApplicationCompositeDataType)]] wikitext text/x-wiki #REDIRECT [[AutosarDataType#Application Composite Data Type (ApplicationCompositeDataType)]] d405008ff5ad22da4d74fa658ce0d7c6f2f1c301 0 1104 1924 2016-01-04T11:28:35Z Oliver 1 Redirected page to [[AutosarDataType#Application Composite Data Type (ApplicationCompositeDataType)]] wikitext text/x-wiki #REDIRECT [[AutosarDataType#Application Composite Data Type (ApplicationCompositeDataType)]] d405008ff5ad22da4d74fa658ce0d7c6f2f1c301 0 1014 1925 1791 2016-01-04T11:31:49Z Oliver 1 /* SwDataDefProps */ wikitext text/x-wiki Similar to other programming languages like “C”, variables need to be defined by some data type. The idea is to keep the Application Level as independent from Implementation Level as possible. Therefore in AUTOSAR 4 the ApplicationDataTypes have been introduced.<br /> The variables that are defined by ApplicationDataTypes are called [[AutosarDataPrototype|AutosarDataPrototypes]] (in C++ you would call it an instance of the class, or an instance of the data type). All ApplicationDataTypes and ImplementationDataTypes are derived from an AutosarDataType and mapped to each other by [[DataTypeMap|DataTypeMaps]].<br /> =SwDataDefProps= The properties of an AutosarDataType (and therefore all ApplicationDataTypes and ImplementationDataTypes) can be defined as SwDataDefProps, whereas only a subset of the properties of SwDataDefProps are applicable for specific data types, dependent on the category. As SwDataDefProps can be defined for several different AUTOSAR elements, the following priority is valid. Properties of a lower number overwrite properties of higher number: # [[McDataInstance]] # [[FlatInstanceDescriptor]] # [[ParameterAccess]] # [[InstantiationDataDefProps]] # [[AutosarDataPrototype]] # [[ImplementationDataType]] # [[ApplicationDataType]] <br />SwDataDefProps are compatible if the following properties are compatible: * [[compuMethod]].[[compuPhysToInternal]] * compuMethod.[[compuInternalToPhys]] * [[dataConstr]] * invalidValue (same value) * swRecordLayout * [[unit]] = Application Data Level (ApplicationDataType) = On Application Data Level ApplicationDataTypes and their AutosarDataPrototypes for ApplicationSwComponentTypes are defined from the application point of view. On this level no implementation details such as bit-size, endianness, etc. are defined so that a [[VFB]] system can be defined by using ApplicationDataTypes only. For integration of the [[Software Component|Software Components]] into the [[ECU]] the ApplicationDataTypes must be mapped to ImplementationDatatypes. An ApplicationDataType is further derived into * ApplicationPrimitiveDataType * ApplicationCompositeDataType ** ApplicationRecordDataType: Equivalent to a struct {} in C language. ** ApplicationArrayDataType: Equivalent to an array [] in C language. The category parameter of an ApplicationDataType is used to define the nature of this data type on application level: {| class="wikitable" |category || Description |- |VALUE || Primitive value. |- |STRUCTURE || A data structure (Record) that contains one or more data elements. Note that these ApplicationRecordElements need to have the same SwAddrMethod (→10.7) defined. |- |ARRAY || A data structure where all ApplicationArrayElements are of the same ApplicationDataType. |- |STRING || Contains a single value interpreted as a text string. |- |VAL_BLK || Same as ARRAY. Only that from Measurement & Calibration point-of-view it is interpreted as an axis. |- |BOOLEAN || Contains a boolean state: TRUE or FALSE. |- |COM_AXIS || A common axis as separate calibration parameter which can be referenced by a CURVE or MAP. |- |RES_AXIS || A rescale axis is a shared axis like COM_AXIS. The difference is that this kind of axis can be used for rescaling. Note that the RES_AXIS is by nature a CURVE which is used to implement a nonlinear scaling (rescale) of the axis. |- |CURVE || Calibration parameter with one input value and one output value. The granularity of implemented functionality can be changed by using different number of axis points. A CURVE has always one input axis and one output axis. The output axis is a characteristic of the curve and every time present but the input axis can be defined within the curve definition or separately. |- |MAP || Calibration parameter with two input values and one output value. The granularity of implemented functionality can be changed by using different number of axis points for y- and x-axis. A MAP has always two input axes and one output axis. The output axis is a characteristic of the map and every time present but the input axes can be defined within the map definition or separately. |} == Application Primitive Data Types (ApplicationPrimitiveDataType) == === ApplicationDataType for Calibration Parameters === Data types for calibration parameters are always described as ApplicationPrimitiveDataTypes, even if they have an internal structure. Their substructure is attached to the SwDataDefProps and needs a special description in order to be compatible with existing calibration techniques (instead of a composition of other AutosarDataTypes) === ApplicationDataType for Single Values (VALUE) === The value of the parameter category is set to VALUE. === ApplicationDataType for Enumerations (VALUE) === An enumeration is usually implemented by using an ApplicationPrimitiveDataType of category VALUE. The mapping of the integer numbers to the enum labels is accomplished via an attached [[CompuMethod]], which is of category [[TEXTTABLE]] . === ApplicationDataType for Textual Strings (STRING) === An ApplicationDataType of category STRING contains a text string that is interpreted as a single value on Application Level. On Implementation Level it is usually represented as an [[ARRAY]] or a [[STRUCTURE]]. Note that both, the ApplicationPrimitiveDataType as well as the ImplementationDataType have to reference the same SwBaseType. === ApplicationDataType for Value Blocks (VAL_BLK) === A Value Block (VAL_BLK) is similar to a Value Array but defines values on an axis (only important for calibration data handling). It is mapped to an [[ARRAY]] on Implementation Data Level. === ApplicationDataType for Boolean (BOOLEAN) === An ApplicationDataType for Boolean is mapped to a [[VALUE]] on Implementation Data Level. === ApplicationDataType for Common Axis (COM_AXIS) === A Common Axis definition is a separate calibration parameter which can be referenced by any [[CURVE]] or [[MAP]]. The benefits by using a common axis is that it saves memory space, because it is stored only one time and can be used in multiple curves or maps. It is mapped to an [[ARRAY]] on Implementation Data Level. === ApplicationDataType for Rescale Axis (RES_AXIS) === A Rescale Axis is also a shared axis like [[COM_AXIS]], the difference is that this kind of axis can be used for rescaling. Note that the RES_AXIS is by nature a [[CURVE]] which is used to implement a nonlinear scaling (rescale) of the axis. In addition to saving memory space via the shared usage like a COM_AXIS, it can compress a huge range to non-linear distributed axis points thus retaining the required accuracy. It is mapped to an [[ARRAY]] on Implementation Data Level. === ApplicationDataType for a Curve (CURVE) === A Curve is a calibration parameter with one input value and one output value. That means output values can be defined depending on the input value. The granularity of implemented functionality can be changed by using different number of axis points. A CURVE has always one input axis and one output axis. The output axis is a characteristic of the curve and every time present but the input axis can be defined within the curve definition or separately. It is mapped to an [[ARRAY]] on Implementation Data Level. === ApplicationDataType for a Map (MAP) === A Map is a calibration parameter with two input values and one output value. That means output values can be defined depending on the input values .The granularity of implemented functionality can be changed by using different number of axis points for y- and x-axis. A MAP has always two input axes and one output axis. The output axis is a characteristic of the map and every time present but the input axes can be defined within the map definition or separately. == Application Composite Data Type (ApplicationCompositeDataType) == Similar to programming languages like “C” structures and data arrays can be defined on Application Data Level via ApplicationCompositeDataTypes. The corresponding types are ApplicationRecordDataTypes, or ApplicationArrayDataTypes. ApplicationRecordDataTypes can contain * ApplicationPrimitiveDataTypes, * ApplicationArrayDataTypes or * other ApplicationRecordDataTypes. === ApplicationRecordDataType (STRUCTURE) === An ApplicationRecordDataType is a compilation of ApplicationRecordElements which themselves are ApplicationDataTypes. An ApplicationRecordElement can be of the following category: [[VALUE]], [[VAL_BLK]], [[STRUCTURE]], [[ARRAY]], [[STRING]], [[BOOLEAN]], [[CURVE]], [[MAP]] The category of an ApplicationRecordDataType has to be set to STRUCTURE. All ApplicationRecordElements need to have the same value configured for [[SwAddrMethod]]. === ApplicationArrayDataType (ARRAY) === An ApplicationArrayDataType consists of one or more ApplicationArrayElements of the same ApplicationDataType. Dependent on the attribute arraySizeSemantics, the number of elements of the ApplicationArrayDataType might vary at run-time between 0 and maxNumberOfElements. The category of an ApplicationArrayElement must be identical to the category of the AutosarDataType that is referenced. It can be of the following category: [[VALUE]], [[VAL_BLK]], [[STRUCTURE]], [[ARRAY]], [[STRING]], [[BOOLEAN]], [[COM_AXIS]], [[RES_AXIS]], [[CURVE]], [[MAP]] For multi-dimensional arrays, an element references another ApplicationArrayDataType. 8c4c9d50123d71cf7b7a175b935b65bc46668154 1926 1925 2016-01-04T11:33:56Z Oliver 1 wikitext text/x-wiki Similar to other programming languages like “C”, variables need to be defined by some data type. The idea is to keep the Application Level as independent from Implementation Level as possible. Therefore in AUTOSAR 4 the ApplicationDataTypes have been introduced.<br /> The variables that are defined by ApplicationDataTypes are called [[AutosarDataPrototype|AutosarDataPrototypes]] (in C++ you would call it an instance of the class, or an instance of the data type). All ApplicationDataTypes and ImplementationDataTypes are derived from an AutosarDataType and mapped to each other by [[DataTypeMap|DataTypeMaps]]. =SwDataDefProps= The properties of an AutosarDataType (and therefore all ApplicationDataTypes and ImplementationDataTypes) can be defined as SwDataDefProps, whereas only a subset of the properties of SwDataDefProps are applicable for specific data types, dependent on the category. As SwDataDefProps can be defined for several different AUTOSAR elements, the following priority is valid. Properties of a lower number overwrite properties of higher number: # [[McDataInstance]] # [[FlatInstanceDescriptor]] # [[ParameterAccess]] # [[InstantiationDataDefProps]] # [[AutosarDataPrototype]] # [[ImplementationDataType]] # [[ApplicationDataType]] <br />SwDataDefProps are compatible if the following properties are compatible: * [[compuMethod]].[[compuPhysToInternal]] * compuMethod.[[compuInternalToPhys]] * [[dataConstr]] * invalidValue (same value) * swRecordLayout * [[unit]] =Application Data Level (ApplicationDataType)= On Application Data Level ApplicationDataTypes and their AutosarDataPrototypes for ApplicationSwComponentTypes are defined from the application point of view. On this level no implementation details such as bit-size, endianness, etc. are defined so that a [[VFB]] system can be defined by using ApplicationDataTypes only. For integration of the [[Software Component|Software Components]] into the [[ECU]] the ApplicationDataTypes must be mapped to ImplementationDatatypes. An ApplicationDataType is further derived into * ApplicationPrimitiveDataType * ApplicationCompositeDataType ** ApplicationRecordDataType: Equivalent to a struct {} in C language. ** ApplicationArrayDataType: Equivalent to an array [] in C language. The category parameter of an ApplicationDataType is used to define the nature of this data type on application level: {| class="wikitable" |- ||category ||Description |- ||VALUE ||Primitive value. |- ||STRUCTURE ||A data structure (Record) that contains one or more data elements. Note that these ApplicationRecordElements need to have the same SwAddrMethod (→10.7) defined. |- ||ARRAY ||A data structure where all ApplicationArrayElements are of the same ApplicationDataType. |- ||STRING ||Contains a single value interpreted as a text string. |- ||VAL_BLK ||Same as ARRAY. Only that from Measurement & Calibration point-of-view it is interpreted as an axis. |- ||BOOLEAN ||Contains a boolean state: TRUE or FALSE. |- ||COM_AXIS ||A common axis as separate calibration parameter which can be referenced by a CURVE or MAP. |- ||RES_AXIS ||A rescale axis is a shared axis like COM_AXIS. The difference is that this kind of axis can be used for rescaling. Note that the RES_AXIS is by nature a CURVE which is used to implement a nonlinear scaling (rescale) of the axis. |- ||CURVE ||Calibration parameter with one input value and one output value. The granularity of implemented functionality can be changed by using different number of axis points. A CURVE has always one input axis and one output axis. The output axis is a characteristic of the curve and every time present but the input axis can be defined within the curve definition or separately. |- ||MAP ||Calibration parameter with two input values and one output value. The granularity of implemented functionality can be changed by using different number of axis points for y- and x-axis. A MAP has always two input axes and one output axis. The output axis is a characteristic of the map and every time present but the input axes can be defined within the map definition or separately. |} ==Application Primitive Data Types (ApplicationPrimitiveDataType)== ===ApplicationDataType for Calibration Parameters=== Data types for calibration parameters are always described as ApplicationPrimitiveDataTypes, even if they have an internal structure. Their substructure is attached to the SwDataDefProps and needs a special description in order to be compatible with existing calibration techniques (instead of a composition of other AutosarDataTypes) ===ApplicationDataType for Single Values (VALUE)=== The value of the parameter category is set to VALUE. ===ApplicationDataType for Enumerations (VALUE)=== An enumeration is usually implemented by using an ApplicationPrimitiveDataType of category VALUE. The mapping of the integer numbers to the enum labels is accomplished via an attached [[CompuMethod]], which is of category [[TEXTTABLE]] . ===ApplicationDataType for Textual Strings (STRING)=== An ApplicationDataType of category STRING contains a text string that is interpreted as a single value on Application Level. On Implementation Level it is usually represented as an [[ARRAY]] or a [[STRUCTURE]]. Note that both, the ApplicationPrimitiveDataType as well as the ImplementationDataType have to reference the same SwBaseType. ===ApplicationDataType for Value Blocks (VAL_BLK)=== A Value Block (VAL_BLK) is similar to a Value Array but defines values on an axis (only important for calibration data handling). It is mapped to an [[ARRAY]] on Implementation Data Level. ===ApplicationDataType for Boolean (BOOLEAN)=== An ApplicationDataType for Boolean is mapped to a [[VALUE]] on Implementation Data Level. ===ApplicationDataType for Common Axis (COM_AXIS)=== A Common Axis definition is a separate calibration parameter which can be referenced by any [[CURVE]] or [[MAP]]. The benefits by using a common axis is that it saves memory space, because it is stored only one time and can be used in multiple curves or maps. It is mapped to an [[ARRAY]] on Implementation Data Level. ===ApplicationDataType for Rescale Axis (RES_AXIS)=== A Rescale Axis is also a shared axis like [[COM_AXIS]], the difference is that this kind of axis can be used for rescaling. Note that the RES_AXIS is by nature a [[CURVE]] which is used to implement a nonlinear scaling (rescale) of the axis. In addition to saving memory space via the shared usage like a COM_AXIS, it can compress a huge range to non-linear distributed axis points thus retaining the required accuracy. It is mapped to an [[ARRAY]] on Implementation Data Level. ===ApplicationDataType for a Curve (CURVE)=== A Curve is a calibration parameter with one input value and one output value. That means output values can be defined depending on the input value. The granularity of implemented functionality can be changed by using different number of axis points. A CURVE has always one input axis and one output axis. The output axis is a characteristic of the curve and every time present but the input axis can be defined within the curve definition or separately. It is mapped to an [[ARRAY]] on Implementation Data Level. ===ApplicationDataType for a Map (MAP)=== A Map is a calibration parameter with two input values and one output value. That means output values can be defined depending on the input values .The granularity of implemented functionality can be changed by using different number of axis points for y- and x-axis. A MAP has always two input axes and one output axis. The output axis is a characteristic of the map and every time present but the input axes can be defined within the map definition or separately. ==Application Composite Data Type (ApplicationCompositeDataType)== Similar to programming languages like “C” structures and data arrays can be defined on Application Data Level via ApplicationCompositeDataTypes. The corresponding types are ApplicationRecordDataTypes, or ApplicationArrayDataTypes. ApplicationRecordDataTypes can contain * ApplicationPrimitiveDataTypes, * ApplicationArrayDataTypes or * other ApplicationRecordDataTypes. ===ApplicationRecordDataType (STRUCTURE)=== An ApplicationRecordDataType is a compilation of ApplicationRecordElements which themselves are ApplicationDataTypes. An ApplicationRecordElement can be of the following category: [[VALUE]], [[VAL_BLK]], [[STRUCTURE]], [[ARRAY]], [[STRING]], [[BOOLEAN]], [[CURVE]], [[MAP]] The category of an ApplicationRecordDataType has to be set to STRUCTURE. All ApplicationRecordElements need to have the same value configured for [[SwAddrMethod]]. ===ApplicationArrayDataType (ARRAY)=== An ApplicationArrayDataType consists of one or more ApplicationArrayElements of the same ApplicationDataType. Dependent on the attribute arraySizeSemantics, the number of elements of the ApplicationArrayDataType might vary at run-time between 0 and maxNumberOfElements. The category of an ApplicationArrayElement must be identical to the category of the AutosarDataType that is referenced. It can be of the following category: [[VALUE]], [[VAL_BLK]], [[STRUCTURE]], [[ARRAY]], [[STRING]], [[BOOLEAN]], [[COM_AXIS]], [[RES_AXIS]], [[CURVE]], [[MAP]] <br />For multi-dimensional arrays, an element references another ApplicationArrayDataType. =Implementation Data Level (ImplementationDataType)= In order to be compatible, the instances of ImplementationDataType must have * the same category * the identical structure (this refers to ImplementationDataTypeElement and their subElements) * identical values for the attributes arraySize and arraySizeSemantics * compatible swDataDefProps attached to the data types 507cf3fe3c8a0d2657658863f97c61640f9368d0 0 1105 1927 2016-01-04T11:34:40Z Oliver 1 Redirected page to [[AutosarDataType#Implementation Data Level (ImplementationDataType)]] wikitext text/x-wiki #REDIRECT [[AutosarDataType#Implementation Data Level (ImplementationDataType)]] ff81935a172870e585af3edbb21bcaec173b5085 0 1106 1928 2016-01-04T11:34:55Z Oliver 1 Redirected page to [[AutosarDataType#Implementation Data Level (ImplementationDataType)]] wikitext text/x-wiki #REDIRECT [[AutosarDataType#Implementation Data Level (ImplementationDataType)]] ff81935a172870e585af3edbb21bcaec173b5085 0 1107 1929 2016-01-11T07:14:32Z Oliver 1 Redirected page to [[In Cable Control Box]] wikitext text/x-wiki #REDIRECT [[In Cable Control Box]] 25fbd3e7db5808f8c4adeed70e43de1cb3382b40 0 117 1931 1697 2016-01-12T10:15:51Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] Software tool which supports one or more tasks in the [[AUTOSAR methodology]]. Depending on the supported tasks, an AUTOSAR tool can act as an [[AUTOSAR authoring tool]], an [[AUTOSAR converter tool]], an [[AUTOSAR processor tool]] or as a combination of those. =Implementers= According to the AUTOSAR-paradigm "Common standard, concurring implementations", several software suppliers offer software implementations of the AUTOSAR standard. Some of the suppliers of AUTOSAR standard software are: {| class="wikitable sortable" |- !|Implementer !|BSW/MCAL Implementation !|BSW Configurator !|RTE Generator !|System Tooling !|License |- ||[http://www.arccore.com/ ArcCore] ||[http://www.arccore.com/products/arctic-core/ Arctic Core - Open source AUTOSAR] ||[http://www.arccore.com/products/bsw-builder/ BSW Builder] ||[http://www.arccore.com/products/rte-builder/ RTE Builder] ||[http://www.arccore.com/products/swc-builder/ SWC Builder] and [http://www.arccore.com/products/test-product-page/ Extract Builder] ||GPL (Arctic Core and base version of Arctic Studio) / Commercial licenses available for all products |- ||[https://www.comasso.org/ COMASSO_eV] ||[https://www.comasso.org/comasso_downloads BSW] ||[https://www.comasso.org/comasso_downloads BSWDT] ||No ||No ||Community |- ||[http://www.conti-online.com/generator/www/de/en/continental/engineering_services/themes/autosar/autosar_overview_en.html Continental Engineering Services] ||[http://www.conti-online.com/generator/www/de/en/continental/engineering_services/themes/autosar/autosar_software_en.html Yes] ||[http://www.conti-online.com/generator/www/de/en/continental/engineering_services/themes/autosar/autosar_tooling_en.html Yes] ||[http://www.conti-online.com/generator/www/de/en/continental/engineering_services/themes/autosar/autosar_tooling_en.html Yes] ||[http://www.conti-online.com/generator/www/de/en/continental/engineering_services/themes/autosar/autosar_tooling_en.html Yes] ||Commercial |- ||[[wikipedia:DSPACE_GmbH|dSPACE]] ||No ||No ||[http://www.dspace.de/en/pub/home/products/sw/system_architecture_software/systemdesk/rte_generation_module_.cfm SystemDesk RTE Generator] ||[http://www.dspace.de/en/pub/home/products/sw/system_architecture_software/systemdesk.cfm SystemDesk] ||Commercial |- ||[[wikipedia:Elektrobit]] ||[http://automotive.elektrobit.com/ecu/autosar EB Tresos AutoCore] ||[http://automotive.elektrobit.com/ecu/eb-tresos-studio EB Tresos Studio] ||[http://automotive.elektrobit.com/ecu/eb-tresos-studio EB Tresos studio] ||No ||Commercial |- ||[[wikipedia:ETAS Group|ETAS]] ||[http://www.etas.com/en/applications_autosar_solutions.php Yes] ||[http://www.etas.com/en/applications_autosar_solutions.php Yes] ||[http://www.etas.com/en/products/rta_software_products.php RTA] ||[http://www.etas.com/en/products/isolar_a.php ISOLAR-A] ||Commercial |- ||[http://www.freescale.com/ Freescale] ||Yes http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=AUTOSAR_CS&tid=vanAutoSAR ||No ||Yes ||Unknown ||Commercial |- ||[http://www.3ds.com/products/catia/portfolio/geensoft/geensoft-product-lines/autosar-builder/ Dassault Systèmes] ||No ||[http://www.3ds.com/products/catia/portfolio/geensoft/geensoft-product-lines/autosar-builder/ GCE] ||[http://www.3ds.com/products/catia/portfolio/geensoft/geensoft-product-lines/autosar-builder/ RTEG] ||[http://www.3ds.com/products/catia/portfolio/geensoft/geensoft-product-lines/autosar-builder/ AAT] ||Commercial |- ||[http://www.hyundai-autron.com/ Hyundai-Autron] ||Yes ||Yes ||Yes ||Yes ||Commercial |- ||[[wikipedia:KPIT Technologies Ltd.]] ||[http://www.kpit.com/engineering/automotive/autosar-in-vehicle-networks#tab-1 K-SAR Suite] ||[http://www.kpit.com/engineering/automotive/autosar-in-vehicle-networks#tab-3 K-SAR Editor] ||[http://www.kpit.com/engineering/automotive/autosar-in-vehicle-networks#tab-3 Yes] ||[http://www.kpit.com/engineering/automotive/autosar-in-vehicle-networks#tab-3 K-SAR Editor] ||Commercial |- ||[[wikipedia:Mecel]] ||[http://www.mecel.se/products/mecel-picea Yes] ||[http://www.mecel.se/products/mecel-picea Yes] ||[http://www.mecel.se/products/mecel-picea Yes] ||Unknown ||Commercial. (Acquired by Mentor Graphics) [http://www.microwavejournal.com/articles/21490], News link. Mentor Graphics acquires Mecel Picea AUTOSAR Development Suite. |- ||[http://www.mentor.com/ Mentor Graphics] ||[http://www.mentor.com/products/vnd/autosar-products/volcano-vstar Volcano VSTAR] ||[http://www.mentor.com/products/vnd/autosar-products/volcano-vstar Volcano VSTAR] ||[http://www.mentor.com/products/vnd/autosar-products/volcano-vstar Volcano VSTAR] ||[http://www.mentor.com/products/vnd/autosar-products/volcano-system-architect/ Volcano Vehicle Systems Architect] ||Commercial |- ||[http://www.opensynergy.com/ OpenSynergy] ||[http://www.opensynergy.com/Products/COQOS COQOS] (OS and BSW Scheduler only) ||[http://www.opensynergy.com/Products/COQOS COQOS] ||[http://www.opensynergy.com/Products/COQOS COQOS] ||No ||Commercial |- ||[[wikipedia:Renesas Electronics]] ||[http://www.renesas.eu/products/tools/middleware_and_drivers/c_autosar/mcal_pkg/mcal_pkg_tools_product_landing.jsp Yes] ||No ||No ||No ||Commercial |- ||[[wikipedia:see4sys]] ||[http://www.see4sys.com Yes] ||[http://www.see4sys.com Yes] ||[http://www.see4sys.com Yes] ||[http://www.see4sys.com ECU-Designer] ||Commercial |- ||[[wikipedia:Vector Informatik|Vector Informatik GmbH]] ||[http://vector.com/vi_microsar_en.html MICROSAR] ||[http://vector.com/vi_autosar_tools_en.html DaVinci Configurator Pro] ||MICROSAR Rte Generator ||[http://vector.com/vi_preevision_en.html PREEvision] / [http://vector.com/vi_davinci_developer_en.html DaVinci Developer] ||Commercial |} 1248f8f4cf2b95d185c32db0b84b40c433cf88eb 0 1 1932 1421 2016-01-12T10:23:23Z Oliver 1 wikitext text/x-wiki Welcome! This '''automotive wiki''' is provided to you by [http://www.scheid-automotive.com SCHEID automotive GmbH]. Feel free to participate in order to improve this wiki. In order to do so, please consider the following * respect copyrights * do not add confidential information * do not create pages that are already covered by the general [https://www.wiki.org Wikipedia]. Instead link to pages of Wikipedia where useful. For browsing [[AUTOSAR]] topics you may want to start with * [[Basic Software Module]]s * [[AUTOSAR Tool]] da63e87ef7c9dda4beb33b68480729d04384ae42 1933 1932 2016-01-12T10:24:28Z Oliver 1 wikitext text/x-wiki Welcome! This '''automotive wiki''' is provided to you by [http://www.scheid-automotive.com SCHEID automotive GmbH]. Feel free to participate in order to improve this wiki. In order to do so, please consider the following * respect copyrights * do not add confidential information * do not create pages that are already covered by the general [https://www.wiki.org Wikipedia]. Instead link to pages of Wikipedia where useful. For browsing [[AUTOSAR]] topics you may want to start with * [[Basic Software Module]]s * List of [[AUTOSAR Tool]]s ce164a5bdcccb19ef42a2f3a34f74fd5344258cb 1939 1933 2016-01-12T14:57:26Z Oliver 1 wikitext text/x-wiki Welcome! This '''automotive wiki''' is provided to you by [http://www.scheid-automotive.com SCHEID automotive GmbH]. Feel free to participate in order to improve this wiki. In order to do so, please consider the following * respect copyrights * do not add confidential information * do not create pages that are already covered by the general [https://www.wiki.org Wikipedia]. Instead link to pages of Wikipedia where useful. For browsing [[AUTOSAR]] topics you may want to start with * [[Basic Software Module]]s * List of [[AUTOSAR Tool]]s * List of [[AUTOSAR links]] c9070d47110431b38902680de288a3cf42a04f3f 14 1108 1934 2016-01-12T14:41:35Z Andreas3 6 Created page with "B - Test" wikitext text/x-wiki B - Test d1e0f244fae2115fcca2bd79507876b2b1c172cc 1937 1934 2016-01-12T14:53:45Z Andreas 2 Blanked the page wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 791 1935 1883 2016-01-12T14:48:18Z Andreas3 6 /* A-sample */ wikitext text/x-wiki =A-sample-= = B-sample = = C-sample = = D-sample = Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] 2866fcd9fe8c759c01154e620db44aaedbdffed3 1936 1935 2016-01-12T14:50:22Z Andreas 2 /* A-sample- */ wikitext text/x-wiki =A-sample= = B-sample = = C-sample = = D-sample = Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] f842d63bb0469149ac9d0c2fbb9ea006d8ab751f 1940 1936 2016-01-12T15:04:23Z Andreas3 6 /* A-sample */ wikitext text/x-wiki =A-sample - = = B-sample = = C-sample = = D-sample = Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] 6f712d08f02730effcb698fefdc042a208dead76 1941 1940 2016-01-12T15:04:33Z Andreas3 6 wikitext text/x-wiki =A-sample= =B-sample= =C-sample= =D-sample= Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] 37ba27c3a49c7980dc34811d0838dc32d8d5da0b 1943 1941 2016-01-14T11:32:32Z Andreas3 6 /* A-sample */ wikitext text/x-wiki =A-sample -= =B-sample= =C-sample= =D-sample= Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] 374e4de97666415f58ed9de8b27a795c5727e1c9 1944 1943 2016-01-16T15:24:36Z Andreas3 6 wikitext text/x-wiki =A-sample -= =B-sample - = =C-sample= =D-sample= Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] d46367a60347bb1695e9b48f114d461eb8e98a96 1945 1944 2016-01-18T11:40:37Z Andreas3 6 /* C-sample */ wikitext text/x-wiki =A-sample -= =B-sample - = =C-sample-= =D-sample= Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] 1fc74854610e47c7d0d00ac5fcb90e422dd96b0d 1949 1945 2016-01-19T12:41:01Z Andreas 2 Rejected the last 3 text changes (by [[Special:Contributions/Andreas3|Andreas3]]) and restored revision 1941 by Andreas3 wikitext text/x-wiki =A-sample= =B-sample= =C-sample= =D-sample= Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] 37ba27c3a49c7980dc34811d0838dc32d8d5da0b 1952 1949 2016-03-02T14:19:43Z Andreas 2 /* A-sample */ wikitext text/x-wiki =A-sample+= =B-sample= =C-sample= =D-sample= Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] d5ea6cb6423ee509b87b1d4a3ab27a32e41811a5 1953 1952 2016-03-02T14:21:08Z Andreas 2 Rejected the last 5 text changes (by [[Special:Contributions/Andreas3|Andreas3]] and [[Special:Contributions/Andreas|Andreas]]) and restored revision 1941 by Andreas3 wikitext text/x-wiki =A-sample= =B-sample= =C-sample= =D-sample= Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] 37ba27c3a49c7980dc34811d0838dc32d8d5da0b 1954 1953 2016-03-02T14:22:22Z Andreas 2 /* A-sample */ wikitext text/x-wiki =A-sample+= =B-sample= =C-sample= =D-sample= Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] d5ea6cb6423ee509b87b1d4a3ab27a32e41811a5 1955 1954 2016-03-02T14:22:55Z Andreas 2 /* A-sample+ */ wikitext text/x-wiki =A-sample= =B-sample= =C-sample= =D-sample= Hardware sample intended for series production [[Category:Hardware]] [[Category:Software]] [[Category:Mechanic]] 0df2495400d7829fcdfab0e2202da9ca0ec1e811 0 1109 1938 2016-01-12T14:57:00Z Oliver 1 Created page with "The following is a list of interesting links to websites about [[AUTOSAR]]: * ..." wikitext text/x-wiki The following is a list of interesting links to websites about [[AUTOSAR]]: * ... 90528682b513c81e212c8dec4263bf16c7fab6d4 0 1096 1942 1915 2016-01-12T15:05:29Z Andreas 2 wikitext text/x-wiki Privacy''' Statement<br />''' '''General''' Your personal data (e.g. title, name, house address, e-mail address, phone number, bank details, credit card number) are processed by us only in accordance with the provisions of German data privacy laws. The following provisions describe the type, scope and purpose of collecting, processing and utilizing personal data. This data privacy policy applies only to our web pages. If links on our pages route you to other pages, please inquire there on how your data are handled in such cases. '''Inventory data''' (1) Your personal data, insofar as these are necessary for this contractual relationship (inventory data) in terms of its establishment, organization of content and modifications, are used exclusively for fulfilling the contract. For goods to be delivered, for instance, your name and address must be relayed to the supplier of the goods.<br />(2) Without your explicit consent or a legal basis, your personal data are not passed on to third parties outside the scope of fulfilling this contract. After completion of the contract, your data are blocked against further use. After expiry of deadlines as per tax-related and commercial regulations, these data are deleted unless you have expressly consented to their further use. '''Piwik''' '''This website uses '''[http://piwik.org/ Piwik], a web analytics open-source software. Piwik uses “cookies”, which are text files placed on your computer, to help the website analyze how users use the site. The information generated by the cookie about your use of the website (including your IP address anonymized prior to its storage) will be stored on the server of the service provider in Germany. You may refuse the use of cookies by selecting the appropriate settings on your browser, however please note that if you do this you may not be able to use the full functionality of this website. {{#widget:Iframe|url=http://piwik.automotive.wiki/index.php?module=CoreAdminHome&action=optOut&language=en|width=900|height=200|border=0}} '''Disclosure''' According to the German Federal Data Protection Act, you have a right to free-of-charge information about your stored data, and possibly entitlement to correction, blocking or deletion of such data. Inquiries can be directed to the following e-mail addresses: ( [mailto:info@scheid-automotive.com info@scheid-automotive.com] ) 3c49ce51e5f70126a8a41ce54fe99b3739a0f7fc 0 974 1946 1698 2016-01-18T11:47:28Z Andreas3 6 /* ADAS */ wikitext text/x-wiki =ADAS= Advanced Driver Assistance System. aedc44875bcc7951afb8c81581f10a7ae8cbe5ad 1950 1946 2016-01-19T12:42:48Z Andreas 2 Rejected the last text change (by [[Special:Contributions/Andreas3|Andreas3]]) and restored revision 1698 by Oliver wikitext text/x-wiki = ADAS = Advanced Driver Assistance System aee4ab353430fd1151570a3bddc2184f5d740b0e 0 159 1951 1622 2016-03-01T11:12:24Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |- ||Abbr. ||Full name ||German full name |- ||SBC ||Sensoric Brake Control ||Elektrohydraulisches Bremssystem |- ||ABS || ||Anti Blockiersystem |- ||ECM ||Engine Control Module || |- ||ESC, ESP ||Electronic Stability Control ||Elektronisches Stabilitätsprogramm |- ||BCM ||Body Control Module<br />Brake Control Module || |- ||IPC ||Instrument Panel Cluster || |- ||LSM ||Light Switch Module || |- ||RSM ||Rain Sensor Module || |- ||TBM ||Trailer Brake Module || |- ||TRM ||Trailer Module || |- ||AFS ||Active Front Steering<br />Advanced Frontlighting System || |- ||TCS ||Traction Control System || |- ||ACC ||Adaptive Cruise Control || |- ||PDC ||Park Distance Control || |- ||(E)SCL ||(Electronic) Steering Column Lock ||ELV = Elektronische Lenkverriegelung |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. dce772c10445f1673cae6d7d19381acda5db03fb 0 118 1956 1092 2016-03-08T09:25:14Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] In [[AUTOSAR]] this means "Filled Template". In fact an AUTOSAR XML description is the [[XML]] representation of an [[AUTOSAR model]]. The AUTOSAR XML description can consist of several files. Each individual file represents an [[AUTOSAR partial model]] and must validate successfully against the [[AUTOSAR XML Schema]]. b19d085f5196c4fb2207b985129e69c8dee6287f 0 1112 1957 2016-03-08T10:02:04Z Oliver 1 Created page with "The multiplicity specifies how often a specific configuration element (module, container, parameter or reference) can occur in the [[ECU Configuration Description]] file.<br /..." wikitext text/x-wiki The multiplicity specifies how often a specific configuration element (module, container, parameter or reference) can occur in the [[ECU Configuration Description]] file.<br /> Examples: * 0..1 One element can occur (optionally). * 1..1 One element is mandatory. * 0..5 Up to five elements can occur (optionally). * 1..5 Up to five elements can occur, but at least one element is mandatory. * 1..* At least one element is mandatory. Can be as many elements as necessary 5397d7b12f6a54faaba14da2035352507a3e8b38 1959 1957 2016-03-08T10:04:19Z Oliver 1 wikitext text/x-wiki The multiplicity specifies how often a specific configuration element (module, container, parameter or reference) can occur in the [[ECU Configuration Description]] file.<br /> Examples: * 0..1 One element can occur (optionally). * 1..1 One element is mandatory. * 0..5 Up to five elements can occur (optionally). * 1..5 Up to five elements can occur, but at least one element is mandatory. * 1..* At least one element is mandatory. Can be as many elements as necessary [[Category:AUTOSAR]] [[Category:Software]] f9dd3a85bebc3119e1bddf30e061a8b7ae7c5cd6 0 448 1958 1366 2016-03-08T10:03:25Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] The Diagnostic Event [[Manager]] (Dem) is a [[Basic Software Module]] of the [[Diagnostic Services]]. Relevant errors are reported either from [[Application Layer]] (resp. [[SW-C]]) or [[Basic Software Module]]s (BSWM). * BSWs report the new status of the event with the Dem_ReportErrorStatus API. * SWCs report the new status of the event with the Dem_SetEventStatus API (through the [[RTE]]) The Diagnostic Event Manager (Dem) handles and stores the [[diagnostic event]]s detected by [[diagnostic monitor]]s in both [[Software Component]]s (SW-Cs) and Basic Software Modules (BSWM). The stored event information is available via an interface to other BSW modules or SW-Cs. ===[[AUTOSAR Interface]]=== ===[[Standardized AUTOSAR Interface]]=== Dem_SetEventStatus CallbackEventStatusChange.EventStatusChanged CallbackEventStatusChange.DTCStatusChanged C/S DiagnosticMonitor.GetEventStatus connected to the Dem_GetEventStatus function ===[[Standardized Interface]]=== * Dem_ReportErrorStatus * Dem_GetVersionInfo ===[[Container]]s and configuration parameters=== Format: ''Container / Parameter {[[Multiplicity]]; Type; ConfigurationClass; Range}'' ''Description'' ====DemConfigSet==== [[Multiplicity]]:=1 ====DemGeneral==== [[Multiplicity]]:=1 DemGeneral/'''DemAgingCycleCounterProcessing''' {1; [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the aging counter is calculated Dem-internally or provided via [[Dem_SetAgingCycleCounterValue]]. * DEM_PROCESS_AGINGCTR_EXTERN: based on [[API]] [[Dem_SetAgingCycleCounterValue]] * DEM_PROCESS_AGINGCTR_INTERN: based on reported cycle states DemGeneral/'''DemBswErrorBufferSize''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of elements in buffer for handling of BSW errors. DemGeneral/'''DemClearDTCBehavior''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} Defines the clearing process of diagnostic information for volatile and [[non-volatile memory]] and the positive response handling for the [[Dcm]] module. * DEM_CLRRESP_NONVOLATILE_FINISH: Return DEM_CLEAR_OK after volatile and non-volatile event memory data cleared. * DEM_CLRRESP_NONVOLATILE_TRIGGER: Return DEM_CLEAR_OK after volatile event memory data cleared and non-volatile event memory clearing is triggered * DEM_CLRRESP_VOLATILE: Return DEM_CLEAR_OK after volatile event memory data cleared DemGeneral/'''DemDTCSuppressionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for [[DTC]] suppression is enabled or not. * TRUE: DTC suppression support is enabled * FALSE: DTC suppression support is disabled DemGeneral/'''DemDebounceCounterBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for counter based debouncing is enabled or not. * TRUE: counter based debouncing support is enabled * FALSE: counter based debouncing support is disabled DemGeneral/'''DemDebounceTimeBasedSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for time based debouncing is enabled or not. * TRUE: time based debouncing support is enabled * FALSE: time based debouncing support is disabled DemGeneral/'''DemDevErrorDetect''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the Development Error Detection and Notification. * TRUE: Development Error Detection and Notification activated * FALSE: DevelopmentError Detection and Notification deactivated DemGeneral/'''DemDtcStatusAvailabilityMask''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Mask for the supported [[DTC]] status bits by the Dem. This mask is used by [[UDS]] service 0x19. DemGeneral/'''DemEnableConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for enable conditions is enabled or not. * TRUE: support for enable conditions is enabled * FALSE: support for enable conditions is disabled DemGeneral/'''DemEventCombinationSupport''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of event combination supported by the Dem. * DEM_EVCOMB_DISABLED: No event combination supported * DEM_EVCOMB_TYPE1: Event combination Type 1 enabled * DEM_EVCOMB_TYPE2: Event combination Type 2 enabled DemGeneral/'''DemEventDisplacementSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for event displacement is enabled or not. * TRUE: event displacement support is enabled * FALSE: event displacement support is disabled DemGeneral/'''DemExtendedDataCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the extended data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of extended data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of extended data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemFreezeFrameCapture''' {0..1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the point in time, when the freeze frame data collection is done for the initial event memory entry. * DEM_TRIGGER_EVENT_MEMORY_STORAGE: Triggers the collection of freeze frame data if the event is stored in fault memory. * DEM_TRIGGER_TESTFAILED: Triggers the collection of freeze frame data if the UDS DTC status bit 0 (TestedFailed) changes from 0 to 1. DemGeneral/'''DemHeaderFileInclusion''' {0..*, [[EcucStringParamDef|String]]; [[Pre-compile time|Pre]]} Name of the header file(s) to be included by the Dem module containing the used C-[[callback]] declarations. DemGeneral/'''DemImmediateNvStorageLimit''' {0..1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} This parameter defines the maximum number of occurrences, a specific event memory entry is allowed, to be stored in [[NVRAM]] immediately (refer to [[DemImmediateNvStorage]]). DemGeneral/'''DemMaxNumberEventEntryMirror''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[mirror memory]]. DemGeneral/'''DemMaxNumberEventEntryPermanent''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[permanent memory]]. The assignment of an event to this memory type is dynamic and used for emission-related events only. DemGeneral/'''DemMaxNumberEventEntryPrimary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 1..255} Maximum number of events which can be stored in the [[primary memory]]. DemGeneral/'''DemMaxNumberEventEntrySecondary''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Maximum number of events which can be stored in the [[secondary memory]]. DemGeneral/'''DemMaxNumberPrestoredFF''' {1, [[EcucIntegerParamDef|Int]]; [[Pre-compile time|Pre]]; 0..255} Defines the maximum number for pre-stored [[freeze frame]]s. If set to 0, then freeze frame pre-storage is not supported by the [[ECU]]. DemGeneral/'''DemOBDSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines whether [[OBD]] is supported or not. DemGeneral/'''DemOccurrenceCounterProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines the consideration of the fault confirmation process for the occurrence counter. For [[OBD]] and mixed systems (OBD/non OBD, refer to [[DemOBDSupport]]) the fault confirmation process must not be considered. * DEM_PROCESS_OCCCTR_CDTC: the occurrence counter is triggered by the TestFailed bit only, but the fault confirmation is not considered * DEM_PROCESS_OCCCTR_TF: the occurrence counter is triggered after the fault confirmation was successful DemGeneral/'''DemOperationCycleProcessing''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[operation cycle]]s are triggered by DEM_CYCLE_STATE_START or collecting an external counter value, which results in respective state changes. * DEM_PROCESS_OPCYC_COUNTER: operation cycle processing is based on [[API]] [[Dem_SetOperationCycleCntValue]] * DEM_PROCESS_OPCYC_STATE: operation cycle processing is based on API [[Dem_SetOperationCycleState]] DemGeneral/'''DemOperationCycleStatusStorage''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the operation cycle state is available over the [[power cycle]] (stored non-volatile) or not. * TRUE: the operation cycle state is stored [[non-volatile]] * FALSE: the operation cycle state is only stored [[volatile]] DemGeneral/'''DemPTOSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether [[PTO]] support (and therefore [[PID]] $1E support) is enabled or not. DemGeneral/'''DemStatusBitHandlingTestFailedSinceLastClear''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This configuration switch defines, whether the [[aging]] and displacement mechanism shall be applied to the "[[TestFailedSinceLastClear]]" status bits. * DEM_STATUS_BIT_AGING_AND_DISPLACEMENT: the "TestFailedSinceLastClear" status bits are reset to 0, if aging or displacement applies (like done for the "[[ConfirmedDTC]]" status bits) * DEM_STATUS_BIT_NORMAL: aging and displacement has no impact on the "TestFailedSinceLastClear" status bits DemGeneral/'''DemStatusBitStorageTestFailed''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the permanent storage of the "[[TestFailed]]" status bits. * TRUE: storage activated * FALSE: storage deactivated DemGeneral/'''DemStorageConditionSupport''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} This configuration switch defines, whether support for storage conditions is enabled or not. * TRUE: support for storage conditions is enabled * FALSE: support for storage conditions is disabled DemGeneral/'''DemTaskTime''' {1, [[EcucFloatParamDef|Float]]; [[Pre-compile time|Pre]]; 0..0.1} Allow to configure the time for the periodic [[cyclic task]]. Please note: This configuration value shall be equal to the value in the [[Basic Software Scheduler]] configuration of the [[RTE]] module. The AUTOSAR configuration standard is to use [[SI unit]]s, so this parameter is defined as float value in seconds. Dem configuration tools must convert this float value to the appropriate value format for the use in the software implementation of Dem. Exactly one DemTaskTime must be specified per configuration. * min: A negative value is not allowed. * max: After event status was reported, processing shall be completed within 100ms in order to have the fault entry status information updated as soon as possible (e.g. for PID $01). DemGeneral/'''DemTriggerDcmReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Diagnostic Communication Manager]] for [[ROE processing]]. * TRUE: Dcm ROE notification activated * FALSE: Dcm ROE notification deactivated DemGeneral/'''DemTriggerDltReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Diagnostic Log and Trace]]. * TRUE: Dlt notification activated * FALSE: Dlt notification deactivated DemGeneral/'''DemTriggerFiMReports''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the notification to the [[Funciton Inhibition Manager]]. * TRUE: FiM notification activated * FALSE: FiM notification deactivated DemGeneral/'''DemTriggerMonitorInitBeforeClearOk''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Defines if the monitor re-initialization has to be triggered before or after the Dem module returns DEM_CLEAR_OK. * TRUE: trigger re-initialization before DEM_CLEAR_OK * FALSE: trigger re-initialization after DEM_CLEAR_OK DemGeneral/'''DemTypeOfDTCSupported''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the format returned by [[Dem_GetTranslationType]] and does not relate to/influence the supported Dem functionality. * DEM_DTC_TRANSLATION_ISO11992_4: [[ISO11992-4]] DTC format * DEM_DTC_TRANSLATION_ISO14229_1: [[ISO14229-1]] DTC format (3 byte format) * DEM_DTC_TRANSLATION_ISO15031_6: [[ISO15031-6]] DTC format (2 byte format) * DEM_DTC_TRANSLATION_SAEJ1939_73: [[SAEJ1939-73]] DTC format DemGeneral/'''DemTypeOfFreezeFrameRecordNumeration''' {1, [[EcucEnumerationParamDef|Enum]]; [[Pre-compile time|Pre]]; ''see below''} This parameter defines the type of assigning [[freeze frame]] record numbers for event-specific freeze frame records. * DEM_FF_RECNUM_CALCULATED: freeze frame records will be numbered consecutive starting by 1 in their chronological order * DEM_FF_RECNUM_CONFIGURED: freeze frame records will be numbered based on the given configuration in their chronological order DemGeneral/'''DemVersionInfoApi''' {1, [[EcucBooleanParamDef|Bool]]; [[Pre-compile time|Pre]]; 0..1} Activate/Deactivate the version information [[API]]. * TRUE: version information activated * FALSE: version information deactivated DemGeneral/'''DemMILIndicatorRef''' {0..1, [[DemIndicator|Reference]]; [[Pre-compile time|Pre]]} This parameter defines the indicator representing the [[MIL]]. This parameter is mandatory for [[ECU]]s supporting [[OBD]] (refer to [[DemOBDSupport]]). 63c0dcd929859675b622baefd6bca4dc7c82a787 0 402 1960 500 2016-03-08T10:06:19Z Oliver 1 wikitext text/x-wiki According to the [[SPEM meta model]], Role Definitions define responsibilities of an individual or a set of individuals and thereby define a set of related skills, competencies, and qualifications needed to perform a [[Task]]. A Role can be filled by one person or multiple people, one person may fill several Roles. Each Role performs Tasks. Roles are not individuals or resources. Individual members of the development organization will wear different hats, or perform different Roles. The mapping from individual to Role, usually performed by the project manager when planning and staffing a project, allows different individuals to act as several different Roles, and for a Role to be taken by several individuals. In the [[AUTOSAR Methodology]], a Role also assigns the responsibility of a Task and defines optional performers. Performers that are responsible for e.g. a Task have a [[multiplicity]] of 1 for the relationship to the Task, optional performers have optional multiplicity assigned. Role Definitions are usually generic and still provide sufficient level of detail for managers to organize a team. Examples of Roles are ”System Engieer”, ”Safety Engineer”, or ”Software Developer”. cf929fc160d625c1e6969491ced932284223fe9b 0 1113 1961 2016-03-14T09:39:17Z Oliver 1 Created page with "MAU = medium access unit HS-MAU = high-speed medium access unit" wikitext text/x-wiki MAU = medium access unit HS-MAU = high-speed medium access unit b069cafc285ee216bc71ac87839e9216e33b9184 1963 1961 2016-03-14T09:40:49Z Oliver 1 wikitext text/x-wiki For [[CAN]] Bus: MAU = medium access unit HS-MAU = high-speed medium access unit [[Category:Hardware]] [[Category:Software]] f98beabad293adf28d2bd74a5c48e80f1abd7fcc 0 1114 1962 2016-03-14T09:39:48Z Oliver 1 Redirected page to [[MAU]] wikitext text/x-wiki #REDIRECT [[MAU]] 2db184039abe5bd87581a4921b62b7e8aae975aa 0 1115 1964 2016-03-14T09:41:26Z Oliver 1 Created page with "medium dependent interface" wikitext text/x-wiki medium dependent interface 2bf8bdafe52bde1af2bca9b3c92a2b20e0422ea7 0 1116 1965 2016-03-14T09:42:00Z Oliver 1 Created page with "For [[CAN]] bus: NBT = nominal bit time [[Category:Hardware]] [[Category:Software]]" wikitext text/x-wiki For [[CAN]] bus: NBT = nominal bit time [[Category:Hardware]] [[Category:Software]] 6064b8bde67fc7a5914010732da29665e842bc6a 0 1117 1966 2016-03-14T09:42:19Z Oliver 1 Created page with "start of frame" wikitext text/x-wiki start of frame 8096830acae3a6285eddd6233e690de6c40a0c3a 0 1118 1967 2016-03-14T09:43:27Z Oliver 1 Created page with "Acknowledge" wikitext text/x-wiki Acknowledge 9beb96dac88f56752e0ce800d691ef1a92595d9b 0 854 1968 1703 2016-03-14T09:46:33Z Oliver 1 Redirected page to [[wikipedia:Carrier sense multiple access]] wikitext text/x-wiki #REDIRECT [[wikipedia:Carrier_sense_multiple_access|Carrier Sense Multiple Access]] 9e6a6beb878a6567da97ac77a3a2eed0b10e4288 0 975 1969 1705 2016-03-14T09:46:50Z Oliver 1 Redirected page to [[wikipedia:Carrier sense multiple access]] wikitext text/x-wiki #REDIRECT [[wikipedia:Carrier_sense_multiple_access|Carrier Sense Multiple Access]] 9e6a6beb878a6567da97ac77a3a2eed0b10e4288 0 1119 1970 2016-03-14T09:47:52Z Oliver 1 Created page with "* End of File * End of Frame (e.g. [[CAN]] bus)" wikitext text/x-wiki * End of File * End of Frame (e.g. [[CAN]] bus) 2670001f49f2bb5354aea40ba77fa81f724e52e1 0 1120 1971 2016-03-14T09:48:12Z Oliver 1 Created page with "Fault Confinement Entity" wikitext text/x-wiki Fault Confinement Entity 779bb6a8c3cb8780fbfe66b93dd67b904e65bd4f 0 1121 1972 2016-03-14T09:48:30Z Oliver 1 Created page with "Logical Link Control" wikitext text/x-wiki Logical Link Control d947f0c684df0f262c9a344c15a1bd1d207f272c 0 1122 1973 2016-03-14T09:48:45Z Oliver 1 Created page with "Layer Management Entity" wikitext text/x-wiki Layer Management Entity de6122e8a6abc19bba1a9449af96f685a50cadaf 0 1123 1974 2016-03-14T09:49:19Z Oliver 1 Created page with "[[LLC]] [[Protocol Data Unit]]" wikitext text/x-wiki [[LLC]] [[Protocol Data Unit]] 46c5ed4633dcc4dcdc80d1ef13eb61834ce96835 0 1124 1975 2016-03-14T09:49:56Z Oliver 1 Created page with "[[LLC]] [[Service Data Unit]]" wikitext text/x-wiki [[LLC]] [[Service Data Unit]] 2d0976c8066bb32422a92f59ee85a1d31cb8097a 0 1125 1976 2016-03-14T09:50:36Z Oliver 1 Created page with "[[MAC]] [[Protocol Data Unit]]" wikitext text/x-wiki [[MAC]] [[Protocol Data Unit]] f0f08d981fd986d4429e3b7db599570929ba3416 0 1126 1977 2016-03-14T09:51:02Z Oliver 1 Created page with "[[MAC]] [[Service Data Unit]]" wikitext text/x-wiki [[MAC]] [[Service Data Unit]] 461f7cf5a21190cb8f17ad38b6045c38468837af 0 1127 1978 2016-03-14T09:52:41Z Oliver 1 Redirected page to [[wikipedia:Media access control]] wikitext text/x-wiki #REDIRECT [[wikipedia:Media_access_control|Media Access Control]] ce0e8ee887dad4a6a71bc1172e3f9053e49c3f69 0 1128 1979 2016-03-14T09:53:36Z Oliver 1 Redirected page to [[wikipedia:Non-return-to-zero]] wikitext text/x-wiki #REDIRECT [[wikipedia:Non-return-to-zero|Non Return to Zero]] 514bf747bae4daf4199129aeb72273272fd08203 0 687 1980 1065 2016-03-14T09:54:39Z Oliver 1 Redirected page to [[wikipedia:Open Systems Interconnection]] wikitext text/x-wiki #REDIRECT [[wikipedia:Open_Systems_Interconnection|Open Systems Interconnection]] ae707baa89591feffc4ea7d3ff04089c4bbbed86 0 1129 1981 2016-03-14T09:54:59Z Oliver 1 Created page with "[[Physical Layer]] Signalling" wikitext text/x-wiki [[Physical Layer]] Signalling 06e9f86d2469b2e8fdf18cad733ad664094d0c0c 0 1130 1982 2016-03-14T09:55:18Z Oliver 1 Created page with "Physical Medium Attachment" wikitext text/x-wiki Physical Medium Attachment a6e7133c50c2f161fe1ea4a96252788ae467c7db 0 1131 1983 2016-03-14T09:55:37Z Oliver 1 Created page with "Remote Transmission Request" wikitext text/x-wiki Remote Transmission Request ed6e37c2a50e2b73a00cf1dea5ec433e7d04e177 0 449 1984 1756 2016-03-14T17:19:22Z Oliver 1 wikitext text/x-wiki for BSW Mode Manager (BswM) see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Complex Device Driver|Complex Device Drivers]] =Services Layer= The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ====Communication Services==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ====Memory Services==== * [[NVRAM Manager]] (NvM) ====System Services==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ====Diagnostic Services==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) =ECU Abstraction Layer= The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ====Communication HW Abstraction==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ====Memory HW Abstraction==== * [[Memory Abstraction Interface]] (MemIf) * [[Flash EEPROM Emulation]] (Fee) * [[EEPROM Abstraction]] (Ea) ====Onboard Device Abstraction==== * [[Watchdog Interface]] (WdgIf) ====I/O HW Abstraction==== * [[IO HW Abstraction]] =Microcontroller Abstraction Layer= The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ====Communication Drivers==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ====I/O Drivers==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ====Memory Drivers==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ====Microcontroller Drivers==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) [[Category:AUTOSAR]] [[Category:Software]] ef1f820517bf95558c77fa9a161bf56ee74d9c75 0 1132 1985 2016-03-16T10:37:29Z Oliver 1 Redirected page to [[Design of Experiments]] wikitext text/x-wiki #REDIRECT [[Design of Experiments]] efca70d44ab9b803311be4bd18e1919c1b14c628 0 1133 1986 2016-03-16T10:37:55Z Oliver 1 Created page with "The method "Design of Experiments" (DoE) is part of the [[Product Validation]] (PV) process of the wikipedia:Advanced_product_quality_planning|Advanced Product Quality Plan..." wikitext text/x-wiki The method "Design of Experiments" (DoE) is part of the [[Product Validation]] (PV) process of the [[wikipedia:Advanced_product_quality_planning|Advanced Product Quality Planning]] (APQP). da2c488457b24a8e1512c14ac9c229652c921b62 0 1134 1987 2016-03-16T10:38:26Z Oliver 1 Redirected page to [[wikipedia:Advanced product quality planning]] wikitext text/x-wiki #REDIRECT [[wikipedia:Advanced_product_quality_planning|Advanced Product Quality Planning]] f0f45886df2d4ccf1815a8d174bd395347cf2172 0 1135 1988 2016-03-21T17:08:46Z Oliver 1 Redirected page to [[External Internal Request Array]] wikitext text/x-wiki #REDIRECT [[External Internal Request Array]] e5433a9f2284ca5eac99853b27c1f731b0dc7f22 1996 1988 2016-03-21T17:23:46Z Oliver 1 Redirected page to [[Partial Network#External Internal Request Array]] wikitext text/x-wiki #REDIRECT [[Partial Network#External Internal Request Array]] 3b08f1c6ad1be0a4bf32acbdb12625d3f62d78d5 0 1136 1989 2016-03-21T17:09:55Z Oliver 1 Created page with "The External Internal Request Array is the aggregated state of the internal/external requested [[Partial Network]]s (PNs). [[Category:AUTOSAR]] [[Category:Software]]" wikitext text/x-wiki The External Internal Request Array is the aggregated state of the internal/external requested [[Partial Network]]s (PNs). [[Category:AUTOSAR]] [[Category:Software]] d486e88e6aa09a529f80354a15fd4e55e01c6cc7 1997 1989 2016-03-21T17:24:09Z Oliver 1 Redirected page to [[Partial Network#External Internal Request Array]] wikitext text/x-wiki #REDIRECT [[Partial Network#External Internal Request Array]] 3b08f1c6ad1be0a4bf32acbdb12625d3f62d78d5 0 1137 1990 2016-03-21T17:19:01Z Oliver 1 Redirected page to [[External Request Array]] wikitext text/x-wiki #REDIRECT [[External Request Array]] 7abecea7ef6df269402ecf4c9bf99ba2f2a6767c 1994 1990 2016-03-21T17:21:48Z Oliver 1 Redirected page to [[Partial Network#External Request Array]] wikitext text/x-wiki #REDIRECT [[Partial Network#External Request Array]] 4cbe99702180570c88335f7148058cfd6aceea2f 0 1138 1991 2016-03-21T17:19:30Z Oliver 1 Created page with "The aggregated state of the external requested [[Partial Network]]s (PNs) is called “External Request Array” (ERA)." wikitext text/x-wiki The aggregated state of the external requested [[Partial Network]]s (PNs) is called “External Request Array” (ERA). afcf43e2861cc01737a181414afba322d0ef7039 1993 1991 2016-03-21T17:21:31Z Oliver 1 Redirected page to [[Partial Network#External Request Array]] wikitext text/x-wiki #REDIRECT [[Partial Network#External Request Array]] 4cbe99702180570c88335f7148058cfd6aceea2f 0 1139 1992 2016-03-21T17:21:03Z Oliver 1 Created page with " = External Request Array = The aggregated state of the external requested [[Partial Network]]s (PNs) is called “External Request Array” (ERA)." wikitext text/x-wiki = External Request Array = The aggregated state of the external requested [[Partial Network]]s (PNs) is called “External Request Array” (ERA). 1e7a05ab3f90cc85e2c7b272a3fe26ee7271f037 1995 1992 2016-03-21T17:23:20Z Oliver 1 wikitext text/x-wiki =External Request Array= The aggregated state of the external requested Partial Networks (PNs) is called “External Request Array” (ERA). = External Internal Request Array = The External Internal Request Array is the aggregated state of the internal/external requested Partial Networks (PNs). [[Category:AUTOSAR]] [[Category:Software]] 48ae04e037618f09a15983f84428cec52d650819 1999 1995 2016-03-22T08:46:20Z Oliver 1 wikitext text/x-wiki =External Request Array= The aggregated state of the external requested Partial Networks (PNs) is called “External Request Array” (ERA). =External Internal Request Array= The External Internal Request Array is the aggregated state of the internal/external requested Partial Networks (PNs). = Car WakeUp = Car WakeUp (CWU) [[Category:AUTOSAR]] [[Category:Software]] 38981ac496116352eca57f8f53385da798f3098d 0 1140 1998 2016-03-22T08:45:57Z Oliver 1 Redirected page to [[Partial Network#Car WakeUp]] wikitext text/x-wiki #REDIRECT [[Partial Network#Car WakeUp]] 5d055cfd57b50a79570040b8fa118fa5c0f5720f 0 1141 2000 2016-03-31T09:01:23Z Oliver 1 Redirected page to [[Module Implementation Prefix]] wikitext text/x-wiki #REDIRECT [[Module Implementation Prefix]] 3206ed9f2cc01b3c02d93afebdb3888769b80c09 0 1142 2001 2016-03-31T09:08:25Z Oliver 1 Created page with "The Module implementation prefix '''Mip''' is structured like: Ma[_vi_ai] * Ma = Module abbreviation of the [[BSW Module]] * vi = vendorId * ai = vendorApiInfix For Compl..." wikitext text/x-wiki The Module implementation prefix '''Mip''' is structured like: Ma[_vi_ai] * Ma = Module abbreviation of the [[BSW Module]] * vi = vendorId * ai = vendorApiInfix For [[Compled Device Driver]]s Mip = apiServicePrefix see AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf [[Category:AUTOSAR]] [[Category:Software]] 02ff9f262dd922dd27672dbf4000e476d7bc9ca5 0 798 2002 1238 2016-04-01T19:32:43Z Oliver 1 Redirected page to [[wikipedia:Change control board]] wikitext text/x-wiki #REDIRECT [[wikipedia:Change_control_board|Change Control Board]] 1f38be470a5ee72b495e52622c435df6f2ebae70 0 885 2003 1382 2016-04-01T19:33:44Z Oliver 1 wikitext text/x-wiki * [[Failure Memory]] (German: Fehlerspeicher) * [[Functional Safety Process]] f7162edbaf91213dbeb9a335664c46f148d985a9 0 808 2004 1282 2016-04-01T19:34:34Z Oliver 1 Redirected page to [[wikipedia:Hardware-in-the-loop simulation]] wikitext text/x-wiki #REDIRECT [[wikipedia:Hardware-in-the-loop_simulation|Hardware in the Loop]] cc95cb8b0b36aa5333a4e300a262fee824eb948e 0 790 2005 1228 2016-04-01T19:35:25Z Oliver 1 Redirected page to [[wikipedia:Configuration management]] wikitext text/x-wiki #REDIRECT [[wikipedia:Configuration_management|Configuration Management]] 8111c8bf8e575dec5bda6138917da3f19a1addec 0 1143 2006 2016-04-01T19:36:02Z Oliver 1 Redirected page to [[Customer Requirement Specification]] wikitext text/x-wiki #REDIRECT [[Customer Requirement Specification]] debdcd8acbbf3ca636ce6b3635fb00c95ec376de 0 1144 2007 2016-04-12T16:07:00Z Oliver 1 Redirected page to [[Design Verification Method]] wikitext text/x-wiki #REDIRECT [[Design Verification Method]] d9aa3ae0a980b72b9fd30661f36fac050f9292b5 0 737 2008 1166 2016-04-12T16:10:16Z Oliver 1 wikitext text/x-wiki * #REDIRECT [[Conducted Immunity]] * #REDIRECT [[Configuration Item]] ec4a812622920bdb22be034c2c539fc22d8d3314 2009 2008 2016-04-12T16:11:21Z Oliver 1 wikitext text/x-wiki * #REDIRECT [[Conducted Immunity]] * #REDIRECT [[wikipedia:Configuration_item|Configuration Item]] 8b0cb3c267cd3b4f5305389b911974edf46a2c6e 0 1145 2010 2016-04-12T16:13:06Z Oliver 1 Redirected page to [[Software Test Plan]] wikitext text/x-wiki #REDIRECT [[Software Test Plan]] f971992e372396d68f61b93e9ab76e93d458c07e 0 1146 2011 2016-04-12T16:13:35Z Oliver 1 Redirected page to [[Software Test Description]] wikitext text/x-wiki #REDIRECT [[Software Test Description]] 56cf386237ceb25987732f17f0e44b94f94448f2 0 1147 2012 2016-04-12T16:15:20Z Oliver 1 Redirected page to [[Software Quality Assurance Plan]] wikitext text/x-wiki #REDIRECT [[Software Quality Assurance Plan]] d51ff4c4db948c6e0928ba91f94ecf3598d1fb6e 0 1148 2013 2016-04-12T16:15:56Z Oliver 1 Redirected page to [[Software Development Plan]] wikitext text/x-wiki #REDIRECT [[Software Development Plan]] d0279db4c42dd5ad54ebe539b72ce25ba928e718 0 1149 2014 2016-04-20T08:49:19Z Oliver 1 Redirected page to [[Hardware Object Handle]] wikitext text/x-wiki #REDIRECT [[Hardware Object Handle]] 85e37ef689805c59d02e4ecaaf87226502787634 0 1150 2015 2016-04-20T08:49:37Z Oliver 1 Redirected page to [[Hardware Object Handle]] wikitext text/x-wiki #REDIRECT [[Hardware Object Handle]] 85e37ef689805c59d02e4ecaaf87226502787634 0 1151 2016 2016-04-20T08:50:04Z Oliver 1 Redirected page to [[Hardware Object Handle]] wikitext text/x-wiki #REDIRECT [[Hardware Object Handle]] 85e37ef689805c59d02e4ecaaf87226502787634 2017 2016 2016-04-20T08:53:10Z Oliver 1 wikitext text/x-wiki Hardware Object Handles (HOH) for transmission (Hardware Transmission Handle, HTH) as well as for reception (Hardware Reception Handle, HRH) represent an abstract reference to a [[CAN]] mailbox structure, that contains CAN related parameters such as CanId, [[DLC]] and data. Based on the CAN hardware buffer abstraction each Hardware Object is referenced in [[CanIf]] independent of the CAN hardware buffer layout. The HOH is used as a parameter in the calls of [[CanDrv]]’s interface services and is provided by CanDrv’s configuration and used by CanDrv as identifier for communication buffers of the CAN [[mailbox]]. [[Category:AUTOSAR]] [[Category:Software]] ef59ae546ed14bf0091d455e88911c2910d77aee 2019 2017 2016-04-20T09:34:09Z Oliver 1 wikitext text/x-wiki Hardware Object Handles (HOH) for transmission (Hardware Transmit Handle, HTH) as well as for reception (Hardware Receive Handle, HRH) represent an abstract reference to a [[CAN]] mailbox structure, that contains CAN related parameters such as CanId, [[DLC]] and data. Based on the CAN hardware buffer abstraction each Hardware Object is referenced in [[CanIf]] independent of the CAN hardware buffer layout. The HOH is used as a parameter in the calls of [[CanDrv]]’s interface services and is provided by CanDrv’s configuration and used by CanDrv as identifier for communication buffers of the CAN [[mailbox]]. [[Category:AUTOSAR]] [[Category:Software]] 44dc69384db40ee1f29a5ad28b58cc09f0d53679 0 1152 2018 2016-04-20T08:54:10Z Oliver 1 Redirected page to [[Hardware Object Handle]] wikitext text/x-wiki #REDIRECT [[Hardware Object Handle]] 85e37ef689805c59d02e4ecaaf87226502787634 0 699 2020 1510 2016-04-20T13:14:25Z Oliver 1 wikitext text/x-wiki * [[Electronic Control Unit#SBC|Sensoric Brake Control]] * [[wikipedia:System_Basis_Chip|System Basis Chip]]s (used e.g. for [[CAN Tranceiver Driver|CAN Transceiver]]s) 65908fb9f691bee745e6698f560f49850da93f8b 0 1153 2021 2016-04-20T13:15:49Z Oliver 1 Redirected page to [[Standard Peripheral Abstraction Layer]] wikitext text/x-wiki #REDIRECT [[Standard Peripheral Abstraction Layer]] 85b28d615a85bd68cf2d9a8777685d1465486722 0 1154 2022 2016-04-20T18:57:18Z Oliver 1 Redirected page to [[Wakeup Pattern]] wikitext text/x-wiki #REDIRECT [[Wakeup Pattern]] f391f5b6122914d68712cd4bc4452fde2fd9b147 0 1155 2023 2016-04-20T18:57:37Z Oliver 1 Redirected page to [[Wakeup Frame]] wikitext text/x-wiki #REDIRECT [[Wakeup Frame]] 72f5f8831f6ce047a17ed8f509f275effddb9a00 0 367 2024 1671 2016-04-25T08:24:16Z Oliver 1 Redirected page to [[ICU Driver]] wikitext text/x-wiki #REDIRECT [[ICU Driver]] 5f239f7f542317fc88fbda449438a43f9c96cef1 0 542 2025 1412 2016-04-25T08:25:55Z Oliver 1 wikitext text/x-wiki The ICU [[Driver]] is a [[Basic Software Module]] of the [[I/O Drivers]] using the Input Capture Unit (ICU) for demodulation of a [[PWM]] signal, counting pulses, measuring of frequency and duty cycle, generating simple interrupts and also wakeup interrupts. ===[[AUTOSAR Interface]]=== ===[[Standardized AUTOSAR Interface]]=== ===[[Standardized Interface]]=== [[Category:AUTOSAR]] 77939e4a2283197d6356eaffe93b74643faec61a 0 1156 2026 2016-05-17T10:31:42Z Oliver 1 Redirected page to [[wikipedia:Special function register]] wikitext text/x-wiki #REDIRECT [[wikipedia:Special_function_register|Special Function Register ]] ee16af5094634a24b74127bf4ab61cf78bc35035 0 964 2027 1645 2016-05-18T07:06:26Z Oliver 1 Redirected page to [[wikipedia:Application programming interface]] wikitext text/x-wiki #REDIRECT [[wikipedia:Application_programming_interface|Application Programming Interface]] 167eb1b4a843f976f19fb21c58d2bc4aab542de9 0 1157 2028 2016-05-18T21:08:18Z Oliver 1 Redirected page to [[Intelligent Communication Controller]] wikitext text/x-wiki #REDIRECT [[Intelligent Communication Controller]] 9e9295cc58512d40365a7907ef96851eb86e6452 0 1158 2029 2016-05-18T21:09:22Z Oliver 1 Created page with "Intelligent Communication Controllers are used for "[[Pretended Networking]]" [[Category:AUTOSAR]] [[Category:Software]] [[Category:Hardware]]" wikitext text/x-wiki Intelligent Communication Controllers are used for "[[Pretended Networking]]" [[Category:AUTOSAR]] [[Category:Software]] [[Category:Hardware]] 38b1b46f355a0b961a19de431e07d4993b6e6c30 0 1159 2030 2016-05-18T21:22:31Z Oliver 1 Redirected page to [[Bit rate switch]] wikitext text/x-wiki #REDIRECT [[Bit rate switch]] c6f3270dc66a8c5c5a39cc0f87565105d5c57aab 0 1160 2031 2016-05-18T21:27:37Z Oliver 1 Redirected page to [[CAN FD]] wikitext text/x-wiki #REDIRECT [[CAN FD]] f76f1d89e49fb845cf6d9e13907db25e28f2ff2f 0 1161 2032 2016-05-18T21:29:37Z Oliver 1 Redirected page to [[CAN Driver]] wikitext text/x-wiki #REDIRECT [[CAN Driver]] 15bb84c00c085823aae7afb554db1cf3974cea9e 0 1162 2033 2016-05-18T21:30:17Z Oliver 1 Created page with "CAN FD (or [[CAN]] with Flexible Data-Rate) allows a different data length as well as optionally switching to a faster bit rate. It supports specific CAN FD frames with bit ra..." wikitext text/x-wiki CAN FD (or [[CAN]] with Flexible Data-Rate) allows a different data length as well as optionally switching to a faster bit rate. It supports specific CAN FD frames with bit rate switch (BRS). See also [[CAN Driver]] [[Category:AUTOSAR]] [[Category:Hardware]] [[Category:Software]] ecc6f8481f4b92d1b8a2a514ccfce0173e74ab42 0 1163 2034 2016-05-19T06:20:11Z Oliver 1 Created page with "For Data Length Code (DLC) see [[CAN]]." wikitext text/x-wiki For Data Length Code (DLC) see [[CAN]]. 8e31c5bb09d1167511847868f0fb3cb3beb5333a 0 1164 2035 2016-06-03T08:59:02Z Oliver 1 Created page with "=Services= {| class="wikitable" |- !|Service ID (hex) !|Service !|Description |- ||0x10 ||Diagnostic Session Control || |- ||0x11 ||ECU Reset || |- ||0x14 ||Clear Diagnostic I..." wikitext text/x-wiki =Services= {| class="wikitable" |- !|Service ID (hex) !|Service !|Description |- ||0x10 ||Diagnostic Session Control || |- ||0x11 ||ECU Reset || |- ||0x14 ||Clear Diagnostic Information || |- ||0x19 ||Read DTC Information || |- ||0x22 ||Read Data By Identifier || |- ||0x23 ||Read Memory By Address || |- ||0x27 ||Security Access || |- ||0x28 ||Communication Control || |- ||0x2E ||Write Data By Identifier || |- ||0x2F ||Input Output Control By Identifier || |- ||0x31 ||Routine Control || |- ||0x34 ||Request Download || |- ||0x35 ||Request Upload || |- ||0x36 ||Transfer Data || |- ||0x37 ||Transfer Exit || |- ||0x3D ||Write Memory By Address || |- ||0x3E ||Tester Present || |- ||0x85 ||Control DTC Setting || |} =Negative response codes= The negative response codes (NRC) are divided into 3 ranges: * 0x00: positiveResponse parameter value for server internal implementation, * 0x01 – 0x7F: communication related negative response codes, * 0x80 – 0xFF: negative response codes for specific conditions that are not correct at the point in time the request is received by the server. These response codes may be utilized whenever response code 0x22 (conditionsNotCorrect) is listed as valid in order to report more specifically why the requested action can not be taken. {| class="wikitable" |- !|value !|responseCode !|Description |- ||0x00 ||positiveResponse ||This response code shall not be used in a negative response message. This positiveResponse parameter value is reserved for server internal implementation. |- ||0x01 - 0x0F ||ISOSAEReserved ||This range of values is reserved by this document for future definition. |- ||0x10 ||generalReject ||This response code indicates that the requested action has been rejected by the server. The generalReject response code shall only be implemented in the server if none of the negative response codes defined in this document meet the needs of the implementation. At no means shall this response code be a general replacement for other response codes defined. |- ||0x11 ||serviceNotSupported ||This response code indicates that the requested action will not be taken because the server does not support the requested service. The server shall send this response code in case the client has sent a request message with a service identifier, which is either unknown or not supported by the server. Therefore this negative response code is not shown in the list of negative response codes to be supported for a diagnostic service, because this negative response code is not applicable for supported services. |- ||0x12 ||subFunctionNotSupported ||This response code indicates that the requested action will not be taken because the server does not support the service specific parameters of the request message. The server shall send this response code in case the client has sent a request message with a known and supported service identifier but with "sub function“ which is either unknown or not supported. |- ||0x13 ||incorrectMessageLengthOrInvalidFormat ||This response code indicates that the requested action will not be taken because the length of the received request message does not match the prescribed length for the specified service or the format of the parameters do not match the prescribed format for the specified service. |- ||0x14 ||responseTooLong ||This response code shall be reported by the server if the response to be generated exceeds the maximum number of bytes available by the underlying network layer. |- ||0x15 - 0x20 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x21 ||busyRepeatReques ||This response code indicates that the server is temporarily too busy to perform the requested operation. In this circumstance the client shall perform repetition of the "identical request message" or "another request message". The repetition of the request shall be delayed by a time specified in the respective implementation documents. Example: In a multi-client environment the diagnostic request of one client might be blocked temporarily by a NRC $21 while a different client finishes a diagnostic task.NOTE If the server is able to perform the diagnostic task but needs additional time to finish the task and prepare the response, the NRC 0x78 shall be used instead of NRC 0x21.This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- ||0x22 ||conditionsNotCorrect ||This response code indicates that the requested action will not be taken because the server prerequisite conditions are not met. |- ||0x23 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x24 ||requestSequenceError ||This response code indicates that the requested action will not be taken because the server expects a different sequence of request messages or message as sent by the client. This may occur when sequence sensitive requests are issued in the wrong order. EXAMPLE A successful SecurityAccess service specifies a sequence of requestSeed and sendKey as sub-functions in the request messages. If the sequence is sent different by the client the server shall send a negative response message with the negative response code 0x24 (requestSequenceError). |- ||0x25 - 0x30 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x31 ||requestOutOfRange ||This response code indicates that the requested action will not be taken because the server has detected that the request message contains a parameter which attempts to substitute a value beyond its range of authority (e.g. attempting to substitute a data byte of 111 when the data is only defined to 100), or which attempts to access a dataIdentifier/routineIdentifer that is not supported or not supported in active session. This response code shall be implemented for all services, which allow the client to read data, write data or adjust functions by data in the server. |- ||0x32 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x33 ||securityAccessDenied ||This response code indicates that the requested action will not be taken because the server's security strategy has not been satisfied by the client. The server shall send this response code if one of the following cases occur: * the test conditions of the server are not met, * the required message sequence e.g. DiagnosticSessionControl, securityAccess is not met, * the client has sent a request message which requires an unlocked server. <br />Beside the mandatory use of this negative response code as specified in the applicable services within this standard, this negative response code can also be used for any case where security is required and is not yet granted to perform the required service. |- ||0x34 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x35 ||invalidKey ||This response code indicates that the server has not given security access because the key sent by the client did not match with the key in the server's memory. This counts as an attempt to gain security. The server shall remain locked and increment its internal securityAccessFailed counter. |- ||0x36 ||exceedNumberOfAttempts ||This response code indicates that the requested action will not be taken because the client has unsuccessfully attempted to gain security access more times than the server's security strategy will allow. |- ||0x37 ||requiredTimeDelayNotExpired ||This response code indicates that the requested action will not be taken because the client's latest attempt to gain security access was initiated before the server's required timeout period had elapsed. |- ||0x38 - 0x4F ||reservedByExtendedDataLinkSecurityDocument ||This range of values is reserved by ISO 15764 Extended data link security. |- ||0x50 - 0x6F ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x70 ||uploadDownloadNotAccepted ||This response code indicates that an attempt to upload/download to a server's memory cannot be accomplished due to some fault conditions. |- ||0x71 ||transferDataSuspended ||This response code indicates that a data transfer operation was halted due to some fault. The active transferData sequence shall be aborted. |- ||0x72 ||generalProgrammingFailure ||This response code indicates that the server detected an error when erasing or programming a memory location in the permanent memory device (e.g. Flash Memory). |- ||0x73 ||wrongBlockSequenceCounter ||This response code indicates that the server detected an error in the sequence of blockSequenceCounter values. Note that the repetition of a TransferData request message with a blockSequenceCounter equal to the one included in the previous TransferData request message shall be accepted by the server. |- ||0x74 - 0x77 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x78 ||requestCorrectlyReceived-ResponsePending ||This response code indicates that the request message was received correctly, and that all parameters in the request message were valid, but the action to be performed is not yet completed and the server is not yet ready to receive another request. As soon as the requested service has been completed, the server shall send a positive response message or negative response message with a response code different from this. The negative response message with this response code may be repeated by the server until the requested service is completed and the final response message is sent. This response code might impact the application layer timing parameter values. The detailed specification shall be included in the data link specific implementation document. This response code shall only be used in a negative response message if the server will not be able to receive further request messages from the client while completing the requested diagnostic service. When this response code is used, the server shall always send a final response (positive or negative) independent of the suppressPosRspMsgIndicationBit value. A typical example where this response code may be used is when the client has sent a request message, which includes data to be programmed or erased in flash memory of the server. If the programming/erasing routine (usually executed out of RAM) is not able to support serial communication while writing to the flash memory the server shall send a negative response message with this response code. This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- ||0x79 - 0x7D ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x7E ||subFunctionNotSupportedInActiveSession ||This response code indicates that the requested action will not be taken because the server does not support the requested sub-function in the session currently active. Within the programmingSession negative response code 0x12 (subFunctionNotSupported) may optionally be reported instead of negative response code 0x7F (subFunctionNotSupportedInActiveSession). This response code shall only be used when the requested sub-function is known to be supported in another session, otherwise response code 0x12 (subFunctionNotSupported) shall be used. This response code shall be supported by each diagnostic service with a sub-function parameter, if not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- ||0x7F ||serviceNotSupportedInActiveSession ||This response code indicates that the requested action will not be taken because the server does not support the requested service in the session currently active. This response code shall only be used when the requested service is known to be supported in another session, otherwise response code 0x11 (serviceNotSupported) shall be used. This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- ||0x80 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x81 ||rpmTooHigh ||This response code indicates that the requested action will not be taken because the server prerequisite condition for RPM is not met (current RPM is above a pre-programmed maximum threshold). |- ||0x82 ||rpmTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for RPM is not met (current RPM is below a pre-programmed minimum threshold). |- ||0x83 ||engineIsRunning ||This is required for those actuator tests which cannot be actuated while the Engine is running. This is different from RPM too high negative response and needs to be allowed. |- ||0x84 ||engineIsNotRunning ||This is required for those actuator tests which cannot be actuated unless the Engine is running. This is different from RPM too low negative response, and needs to be allowed. |- ||0x85 ||engineRunTimeTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for engine run time is not met (current engine run time is below a preprogrammed limit). |- ||0x86 ||temperatureTooHigh ||This response code indicates that the requested action will not be taken because the server prerequisite condition for temperature is not met (current temperature is above a preprogrammed maximum threshold). |- ||0x87 ||temperatureTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for temperature is not met (current temperature is below a preprogrammed minimum threshold). |- ||0x88 ||vehicleSpeedTooHigh ||This response code indicates that the requested action will not be taken because the server prerequisite condition for vehicle speed is not met (current VS is above a pre-programmed maximum threshold). |- ||0x89 ||vehicleSpeedTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for vehicle speed is not met (current VS is below a pre-programmed minimum threshold). |- ||0x8A ||throttle/PedalTooHigh ||This response code indicates that the requested action will not be taken because the server prerequisite condition for throttle/pedal position is not met (current TP/APP is above a preprogrammed maximum threshold). |- ||0x8B ||throttle/PedalTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for throttle/pedal position is not met (current TP/APP is below a preprogrammed minimum threshold). |- ||0x8C ||transmissionRangeNotInNeutral ||This response code indicates that the requested action will not be taken because the server prerequisite condition for being in neutral is not met (current transmission range is not in neutral). |- ||0x8D ||transmissionRangeNotInGear ||This response code indicates that the requested action will not be taken because the server prerequisite condition for being in gear is not met (current transmission range is not in gear). |- ||0x8E ||ISOSAEReserved ||This range of values is reserved by this document for future definition. |- ||0x8F ||brakeSwitch(es)NotClosed (Brake Pedal not pressed or not applied) ||For safety reasons, this is required for certain tests before it begins, and must be maintained for the entire duration of the test. |- ||0x90 ||shifterLeverNotInPark ||For safety reasons, this is required for certain tests before it begins, and must be maintained for the entire duration of the test. |- ||0x91 ||torqueConverterClutchLocked ||This response code indicates that the requested action will not be taken because the server prerequisite condition for torque converter clutch is not met (current TCC status above a preprogrammed limit or locked). |- ||0x92 ||voltageTooHigh ||This response code indicates that the requested action will not be taken because the server prerequisite condition for voltage at the primary pin of the server (ECU) is not met (current voltage is above a pre-programmed maximum threshold). |- ||0x93 ||voltageTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for voltage at the primary pin of the server (ECU) is not met (current voltage is below a pre-programmed maximum threshold). |- ||0x94 - 0xFE ||reservedForSpecificConditionsNotCorrect ||This range of values is reserved for future definition. |- ||0xFF ||ISOSAEReserved ||This range of values is reserved for future definition. |} =DTC Status Byte= {| class="wikitable" |- !|bit # !|hex !|state !|description |- ||0 ||0x01 ||testFailed ||DTC failed at the time of the request |- ||1 ||0x02 ||testFailedThisOperationCycle ||DTC failed on the current operation cycle |- ||2 ||0x04 ||pendingDTC ||DTC failed on the current or previous operation cycle |- ||3 ||0x08 ||confirmedDTC ||DTC is confirmed at the time of the request |- ||4 ||0x10 ||testNotCompletedSinceLastClear ||DTC test not completed since the last code clear |- ||5 ||0x20 ||testFailedSinceLastClear ||DTC test failed at least once since last code clear |- ||6 ||0x40 ||testNotCompletedThisOperationCycle ||DTC test not completed this operation cycle |- ||7 ||0x80 ||warningIndicatorRequested ||Server is requesting warningIndicator to be active |} 5e435dcae9e39e1c9a8421aaf29df1ed74b0a9e3 0 840 2036 1291 2016-06-03T08:59:38Z Oliver 1 Redirected page to [[ISO 14229#Negative response codes]] wikitext text/x-wiki #REDIRECT [[ISO 14229#Negative response codes]] 46acdbf49587ebd537d62ac2ed9db2e7121a0fbb 0 838 2037 1288 2016-06-03T09:00:59Z Oliver 1 Redirected page to [[ISO 14229#Negative response codes]] wikitext text/x-wiki #REDIRECT [[ISO 14229#Negative response codes]] 46acdbf49587ebd537d62ac2ed9db2e7121a0fbb 0 905 2038 1526 2016-06-03T09:01:08Z Oliver 1 Redirected page to [[ISO 14229#Services]] wikitext text/x-wiki #REDIRECT [[ISO 14229#Services]] 77d734a332539e25a14729d82428cd12ef12c86f 0 1165 2039 2016-06-03T09:02:32Z Oliver 1 Redirected page to [[ISO 14229#DTC Status Byte]] wikitext text/x-wiki #REDIRECT [[ISO 14229#DTC Status Byte]] 8929804df7d8197f7c4bb62877e877868f0a3175 0 1095 2040 1930 2016-08-02T08:15:09Z Oliver 1 wikitext text/x-wiki ==='''Legal Disclosure'''=== Information in accordance with section 5 TMG '''SCHEID automotive GmbH'''<br />Obermühlteich 12<br />76646 Bruchsal '''Contact'''<br />Phone: +49 7251-936991-0<br />E-Mail: [mailto:info@SCHEID-automotive.com info@SCHEID-automotive.com]<br />Website: [http://www.scheid-automotive.com/ www.SCHEID-automotive.com] Geschäftsführer / Managing Director: Oliver Scheid<br />Sitz der Gesellschaft / registered office: Bruchsal<br />Registergericht / Register Court: Amtsgericht Mannheim HRB 713257.<br />Steuernummer USt-IdNr. / VAT No.: DE 280101340 '''Person responsible for content in accordance with 55 Abs. 2 RStV'''<br />Oliver Scheid ==='''Disclaimer'''=== '''Accountability for content'''<br />The contents of our pages have been created with the utmost care. However, we cannot guarantee the contents’ accuracy, completeness or topicality. According to statutory provisions, we are furthermore responsible for our own content on these web pages. In this context, please note that we are accordingly not obliged to monitor merely the transmitted or saved information of third parties, or investigate circumstances pointing to illegal activity. Our obligations to remove or block the use of information under generally applicable laws remain unaffected by this as per §§ 8 to 10 of the Telemedia Act (TMG). '''Accountability for links'''<br />Responsibility for the content of external links (to web pages of third parties) lies solely with the operators of the linked pages. No violations were evident to us at the time of linking. Should any legal infringement become known to us, we will remove the respective link immediately. '''Copyright'''<br />Our web pages and their contents are subject to German copyright law. Unless expressly permitted by law (§ 44a et seq. of the copyright law), every form of utilizing, reproducing or processing works subject to copyright protection on our web pages requires the prior consent of the respective owner of the rights. Individual reproductions of a work are allowed only for private use, so must not serve either directly or indirectly for earnings. Unauthorized utilization of copyrighted works is punishable (§ 106 of the copyright law). dfa9ba69d1c227f2d7d7fe3f0c61439609eae03e 0 1166 2041 2016-08-03T14:39:05Z Oliver 1 Created page with "Forward Collision Warning (German: Auffahrwarnsystem)" wikitext text/x-wiki Forward Collision Warning (German: Auffahrwarnsystem) 7414fbdeb93d95ac1796cc93b769510660dd8071 0 1167 2042 2016-08-03T14:39:30Z Oliver 1 Created page with "Autonomous Emergency Braking (German: Autonome Notbremsung)" wikitext text/x-wiki Autonomous Emergency Braking (German: Autonome Notbremsung) e1b022aabdb84343b30b931506320759a13dcf27 0 159 2043 1951 2016-08-03T14:40:32Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |- ||Abbr. ||Full name ||German full name |- ||SBC ||Sensoric Brake Control ||Elektrohydraulisches Bremssystem |- ||ABS || ||Anti Blockiersystem |- ||ECM ||Engine Control Module || |- ||ESC, ESP ||Electronic Stability Control ||Elektronisches Stabilitätsprogramm |- ||BCM ||Body Control Module<br />Brake Control Module || |- ||IPC ||Instrument Panel Cluster || |- ||LSM ||Light Switch Module || |- ||RSM ||Rain Sensor Module || |- ||TBM ||Trailer Brake Module || |- ||TRM ||Trailer Module || |- ||AFS ||Active Front Steering<br />Advanced Frontlighting System || |- ||TCS ||Traction Control System || |- ||ACC ||Adaptive Cruise Control ||<div data-canvas-width="23.386666666666663">Abstandsregel-Tempomat</div> |- ||PDC ||Park Distance Control || |- ||(E)SCL ||(Electronic) Steering Column Lock ||ELV = Elektronische Lenkverriegelung |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 29e221ff4f5f42be5c757d6e86b318f034b108b2 2054 2043 2016-08-30T12:10:11Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |- ||Abbr. ||Full name ||German full name |- ||SBC ||Sensoric Brake Control ||Elektrohydraulisches Bremssystem |- ||ABS || ||Anti Blockiersystem |- ||ECM ||Engine Control Module || |- ||ESC, ESP ||Electronic Stability Control ||Elektronisches Stabilitätsprogramm |- ||BCM ||Body Control Module<br />Brake Control Module || |- ||IPC ||Instrument Panel Cluster || |- ||LSM ||Light Switch Module || |- ||RSM ||Rain Sensor Module || |- ||TBM ||Trailer Brake Module || |- ||TRM ||Trailer Module || |- ||AFS ||Active Front Steering<br />Advanced Frontlighting System || |- ||TCS ||Traction Control System || |- ||ACC ||Adaptive Cruise Control ||<div data-canvas-width="23.386666666666663">Abstandsregel-Tempomat</div> |- ||PDC ||Park Distance Control || |- ||PAM ||Park Assist Module ||Parkassistent |- ||(E)SCL ||(Electronic) Steering Column Lock ||ELV = Elektronische Lenkverriegelung |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. 51bf9b791e2e3209d8f2288f45986236f7775b9a 2061 2054 2016-10-26T21:54:38Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |- ||Abbr. ||Full name ||German full name |- ||SBC ||Sensoric Brake Control ||Elektrohydraulisches Bremssystem |- ||ABS || ||Anti Blockiersystem |- ||ECM ||Engine Control Module || |- ||ESC, ESP ||Electronic Stability Control ||Elektronisches Stabilitätsprogramm |- ||BCM ||Body Control Module<br />Brake Control Module || |- ||IPC ||Instrument Panel Cluster || |- ||LSM ||Light Switch Module || |- ||RSM ||Rain Sensor Module || |- ||TBM ||Trailer Brake Module || |- ||TRM ||Trailer Module || |- ||AFS ||Active Front Steering<br />Advanced Frontlighting System || |- ||TCS ||Traction Control System || |- ||ACC ||Adaptive Cruise Control ||<div data-canvas-width="23.386666666666663">Abstandsregel-Tempomat</div> |- ||PDC ||Park Distance Control || |- ||PAM ||Park Assist Module ||Parkassistent |- ||(E)SCL ||(Electronic) Steering Column Lock ||ELV = Elektronische Lenkverriegelung |- ||BMS ||Battery Management System || |- ||CMC ||Cell Module Controller || |- ||BJB ||Battery Junction Box || |- ||ESS ||Energy Storage System || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. ed2718dda01cd51da93d901cb93dbf4243a7596a 0 1168 2044 2016-08-03T14:41:02Z Oliver 1 Created page with "Lane Demparture Warning (German: Spurhalteassistent)" wikitext text/x-wiki Lane Demparture Warning (German: Spurhalteassistent) 2b505e512b9b19e2e7d13224027fbbca846f3a7b 0 1169 2045 2016-08-03T14:41:24Z Oliver 1 Created page with "Traffic Sign Recognition (German: Verkehrszeichenerkennung)" wikitext text/x-wiki Traffic Sign Recognition (German: Verkehrszeichenerkennung) 25eb733d95243ce32902a33448b7cd363801ba74 0 1170 2046 2016-08-03T14:41:44Z Oliver 1 Created page with "Brake Light Detection (German: Bremslichterkennung)" wikitext text/x-wiki Brake Light Detection (German: Bremslichterkennung) ee5acd959a3f4144093d3b814f49d44fa8cc203c 0 1171 2047 2016-08-03T14:44:32Z Oliver 1 Created page with "Lane Keeping Support (German: Spurhalteassistent)" wikitext text/x-wiki Lane Keeping Support (German: Spurhalteassistent) 3507da929cbf148753c55a3f2d5bc56df29112ce 0 1172 2048 2016-08-03T14:45:32Z Oliver 1 Created page with "Pedestrian Detection (German: Fußgängererkennung)" wikitext text/x-wiki Pedestrian Detection (German: Fußgängererkennung) d023e2ca953b5eee9b9b96b7dd352cdb32036bf3 0 1173 2049 2016-08-03T14:45:58Z Oliver 1 Created page with "Blind Spot Detection (German: Toter-Winkel-Erkennung)" wikitext text/x-wiki Blind Spot Detection (German: Toter-Winkel-Erkennung) b15448c090941ba1a720fe8577d7b717ca481ea8 0 1174 2050 2016-08-03T14:46:35Z Oliver 1 Created page with "Driver Condition Detection (German: Fahrerüberwachung)" wikitext text/x-wiki Driver Condition Detection (German: Fahrerüberwachung) ba4780e6988cb67aa1cbf4e3ab64773cf75b66d4 0 1175 2051 2016-08-03T14:47:13Z Oliver 1 Created page with "Parking Lot Assistant (German: Parkplatzassistent)" wikitext text/x-wiki Parking Lot Assistant (German: Parkplatzassistent) 676edd95b84a8e93b9626103952e48c56328ca3f 0 1176 2052 2016-08-09T06:11:53Z Oliver 1 Created page with "#REDIRECT [[[[wikipedia:Volvo_Cars|Volvo Car Corporation]]]]" wikitext text/x-wiki #REDIRECT [[[[wikipedia:Volvo_Cars|Volvo Car Corporation]]]] 3254e6295be0b7d816b51b0f0a5ccb09a903e78e 0 1177 2053 2016-08-09T06:13:37Z Oliver 1 Created page with "[http://www.cevt.se China Euro Vehicle Technology AB]" wikitext text/x-wiki [http://www.cevt.se China Euro Vehicle Technology AB] ab91d84452d0d4eec301270db7ece14f93f8525b 0 1178 2055 2016-08-30T12:11:15Z Oliver 1 Created page with "* Parking Assist Module (see [[Electronic Control Unit]]) * Process Assessment Model (see [[wikipedia:IEC_15504|Automotive SPICE, ISO/IEC 15504]] )" wikitext text/x-wiki * Parking Assist Module (see [[Electronic Control Unit]]) * Process Assessment Model (see [[wikipedia:IEC_15504|Automotive SPICE, ISO/IEC 15504]] ) 0dc1fa7389f64a9916402000b66afc715355a278 0 1022 2056 1802 2016-08-30T12:12:47Z Oliver 1 wikitext text/x-wiki * Process Reference Model (see [[wikipedia:IEC_15504|Automotive SPICE, ISO/IEC 15504]] ) 9cb910055ec78127dfc21062d3bf62260e591e80 0 1179 2057 2016-09-26T14:31:29Z Oliver 1 Created page with "The MPC56xx microcontrollers family from [http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/mpc5xxx-5xxx-32-bit-mcus/mpc56xx-mcus:MPC56..." wikitext text/x-wiki The MPC56xx microcontrollers family from [http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/mpc5xxx-5xxx-32-bit-mcus/mpc56xx-mcus:MPC56XX NXP] (formerly Freescale) is also called '''Bolero'''. It's "usual" successor is the [[Calypso]]. 51d7030d5c90fb18646ff78704827f3e618baa31 0 1180 2058 2016-09-26T14:32:43Z Oliver 1 Created page with "The MPC57xx microcontrollers family from [http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/mpc5xxx-5xxx-32-bit-mcus/mpc57xx-mcus:MPC57..." wikitext text/x-wiki The MPC57xx microcontrollers family from [http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/mpc5xxx-5xxx-32-bit-mcus/mpc57xx-mcus:MPC57XX NXP] (formerly Freescale) is also called '''Calypso'''. It's "usual" predecessor is the [[Bolero]]. 9a5234c1ce2736ecd88f54576c12f398ab99b3ea 0 1181 2059 2016-10-12T16:00:16Z Oliver 1 Created page with "Master In Slave Out, see [[Serial Peripheral Interface|Serial Peripheral Interface (SPI)]]." wikitext text/x-wiki Master In Slave Out, see [[Serial Peripheral Interface|Serial Peripheral Interface (SPI)]]. a7a0cc1acc1ec58008636967a5d46fd96b7d9208 0 1182 2060 2016-10-12T16:00:38Z Oliver 1 Created page with "Master Out Slave In, see [[Serial Peripheral Interface|Serial Peripheral Interface (SPI)]]." wikitext text/x-wiki Master Out Slave In, see [[Serial Peripheral Interface|Serial Peripheral Interface (SPI)]]. 7fb8975bef78234d0dd057a7ddd8a7fd31f6cd50 0 837 2062 1287 2016-11-02T08:08:49Z Oliver 1 Redirected page to [[ISO 14229#Negative response codes]] wikitext text/x-wiki #REDIRECT [[ISO 14229#Negative response codes]] 46acdbf49587ebd537d62ac2ed9db2e7121a0fbb 0 1183 2063 2017-05-09T10:45:27Z Oliver 1 Created page with "[[Functional Safety]] Board" wikitext text/x-wiki [[Functional Safety]] Board 51b48b5cd51cb9054bc6ff3fad9394ab762f0c48 0 1184 2064 2017-05-09T10:46:15Z Oliver 1 Created page with "<span id="polarion_source=End2End/Specification/End-to-End _E2E_ communication specification for the TS project" data-prototype="Document"></span>System Architectural Board" wikitext text/x-wiki <span id="polarion_source=End2End/Specification/End-to-End _E2E_ communication specification for the TS project" data-prototype="Document"></span>System Architectural Board c88c8533fcea3753ea7e5735e2efe0cbfd4f1cf3 0 1185 2065 2017-05-09T10:48:33Z Oliver 1 Created page with "Fault Tolerant Time Interval" wikitext text/x-wiki Fault Tolerant Time Interval fc300b1bfee78a53206c5041c2da11ac29d8bc61 0 1186 2066 2017-05-17T15:49:47Z Oliver 1 Created page with "The compiler abstraction specifies definitions and macros for the abstraction of compiler specific keywords used for addressing data and code (pointers, variables, function e..." wikitext text/x-wiki The compiler abstraction specifies definitions and macros for the abstraction of compiler specific keywords used for addressing data and code (pointers, variables, function etc.) within declarations and definitions. The file '''Compiler_Cfg.h''' contains the module / component specific parameters (ptrclass and memclass) that are passed to the macros defined in '''Compiler.h'''. ==Definitions== {| |- || '''Define''' || '''Description''' |- || AUTOMATIC || Empty definition, used for the declaration of local pointers. |- || TYPEDEF || Empty definition, used within type definitions, where no memory qualifier can be specified. |- || NULL_PTR || NULL Pointer ((void *)0) |- || INLINE || Define for abstraction of the keyword “inline”. |- || LOCAL_INLINE || Define for abstraction of the keyword “inline” in functions with “static” scope. |} ==Memory Classes and Pointer Classes== In the following table the is derived from the Software Component’s shortName. {| |- || '''Memory type''' || '''Syntax of memory class (memclass) and pointer class (ptrclass) macro parameter''' || '''To be used for…''' |- || Code ||_CODE || code |- || Constants ||_CONST || global or static constants |- || Pointer ||_APPL_DATA || references on application data (expected to be in RAM or ROM) passed via API |- || Pointer ||_APPL_CONST || references on application constants (expected to be certainly in ROM, for instance pointer of Init-function) passed via API |- || Pointer ||_APPL_CODE || references on application functions. (e.g. call back function pointers) |- || Variables ||_CALLOUT_CODE || references on application functions. (e.g. callout function pointers) |- || Variables ||_VAR_NOINIT || all global or static variables that are never initialized |- || Variables ||_VAR_POWER_ON_INIT || all global or static variables that are initialized only after power on reset |- || Variables ||_VAR_FAST || all global or static variables that have at least one of the following properties: * accessed bitwise * frequently used * high number of accesses in source code |- || Variables ||_VAR || global or static variables that are initialized after every reset. |- || Variables || AUTOMATIC || local non static variables |- || Type Definitions || TYPEDEF || type definitions where no memory qualifier can be specified. |} ==Macros for Functions, Pointers, Constants and Variables== These macros ensure correct syntax of definitions and declarations independent of any specific compiler. {| |- || '''Short description and example''' || Function declaration and definition FUNC( void, SwctShortName_CODE ) RunnableCode( void ); || Function returning a pointer to a constant FUNC_P2CONST( uint16, _PBCFG, SwctShortName_CODE )   ExampleFunction( void ); || Function returning a pointer to a variable FUNC_P2VAR( uint16, _PBCFG, SwctShortName_CODE )   ExampleFunction( void ); || Pointer to variable P2VAR( uint8, SPI_VAR_FAST, SPI_APPL_DATA )   Spi_FastPointerToApplData; || Pointer to constant P2CONST( Eep_ConfigType, EEP_VAR, EEP_APPL_CONST )   Eep_ConfigurationPtr; || Constant pointer to variable CONSTP2VAR( uint8, NVM_VAR, NVM_APPL_DATA )   NvM_PointerToRamMirror = Appl_RamMirror; || Constant pointer to constant CONSTP2CONST( Can_PBCfgType, CAN_CONST, CAN_PBCFG_CONST )   Can_PostbuildCfgData = CanPBCfgDataSet; || Pointer to function typedef P2FUNC( void, NVM_APPL_CODE, NvM_CbkFncPtrType )(void); || Constant CONST( uint8, NVM_CONST ) NvM_ConfigurationData; || Variable VAR( uint8, AUTOMATIC ) NvM_VeryFrequentlyUsedState; || ''fctname'':             function name respectively name of the defined type ''memclass'':          classification of the function/pointer/constant/variable itself ''ptrclass'':              classification of the pointer’s distance →13.1.2 |- || '''Macro usage (define)''' || FUNC( rettype, memclass ) || FUNC_P2CONST(rettype, ptrclass, memclass) || FUNC_P2VAR(rettype, ptrclass, memclass) || P2VAR(ptrtype, memclass, ptrclass) || P2CONST(ptrtype, memclass, ptrclass) || CONSTP2VAR (ptrtype, memclass, ptrclass) || CONSTP2CONST(ptrtype, memclass, ptrclass) || P2FUNC(rettype, ptrclass, fctname) || CONST(consttype, memclass) || VAR(vartype, memclass) || ''vartype'':              type of the variable ''consttype'':          type of the constant ''retype'':                 return type of the function ''ptrtype'':               type of the referenced variable/constant |- || '''Macro''' || FUNC || FUNC_P2CONST || FUNC_P2VAR || P2VAR || P2CONST || CONSTP2VAR || CONSTP2CONST || P2FUNC || CONST || VAR |} [[Category:AUTOSAR]] [[Category:Software]] 3ddcd2c3ceaef401e6037275089f8dec9954035e 0 1187 2067 2017-05-17T15:50:00Z Oliver 1 Redirected page to [[Compiler Abstraction]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction]] 37639e1ea2582129e338d28e59031b4bb42d7e36 0 1188 2068 2017-05-17T15:54:37Z Oliver 1 Redirected page to [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] 3dcde88cde56247f63442b64fd98c75500165529 0 1189 2069 2017-05-17T15:54:55Z Oliver 1 Redirected page to [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] 3dcde88cde56247f63442b64fd98c75500165529 0 1190 2070 2017-05-17T15:55:12Z Oliver 1 Redirected page to [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] 3dcde88cde56247f63442b64fd98c75500165529 0 1191 2071 2017-05-17T15:55:35Z Oliver 1 Redirected page to [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] 3dcde88cde56247f63442b64fd98c75500165529 0 1192 2072 2017-05-17T15:55:50Z Oliver 1 Redirected page to [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] 3dcde88cde56247f63442b64fd98c75500165529 0 1193 2073 2017-05-17T15:56:08Z Oliver 1 Redirected page to [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] 3dcde88cde56247f63442b64fd98c75500165529 0 1194 2074 2017-05-17T15:56:24Z Oliver 1 Redirected page to [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] 3dcde88cde56247f63442b64fd98c75500165529 0 1195 2075 2017-05-17T15:56:40Z Oliver 1 Redirected page to [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] 3dcde88cde56247f63442b64fd98c75500165529 0 1196 2076 2017-05-17T15:56:59Z Oliver 1 Redirected page to [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] 3dcde88cde56247f63442b64fd98c75500165529 0 1197 2077 2017-05-17T15:57:14Z Oliver 1 Redirected page to [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] wikitext text/x-wiki #REDIRECT [[Compiler Abstraction#Macros for Functions, Pointers, Constants and Variables]] 3dcde88cde56247f63442b64fd98c75500165529 0 1198 2078 2017-05-17T16:38:57Z Oliver 1 Created page with "In order to prevent unnecessary memory gaps (unused space in RAM), variables of different size (8, 16 and 32 bit) are mapped to specific memory sections depending on their siz..." wikitext text/x-wiki In order to prevent unnecessary memory gaps (unused space in RAM), variables of different size (8, 16 and 32 bit) are mapped to specific memory sections depending on their size. Variables that do not need to be initialized after power-on reset can be mapped to a RAM section that is not initialized after a reset. Variables that are accessed via bit masks can be located within a RAM section that allows for bit manipulation instructions of the compiler (“Near Page” or “Zero Page”). When using external flash memory, modules with functions that are called very often can be mapped to the internal flash memory for faster access. Modules with functions that are called rarely or that have lower performance requirements can be mapped to external flash memory. Internal variables can be mapped into protected memory for memory protection, buffers for data exchange are mapped into unprotected memory. In order to support Partitions an additional separation of the module variables into different memory areas (of the Partitions) is supported. All memory allocated by the RTE is wrapped in segment declarations defined in the specification of Memory Mapping using RTE as the <MSN> (Module Short Name). * Basic Software Modules include '''MemMap.h''' * Software Components include '''''<SWCT>''''''''_MemMap.h<br /> '''(''SWCT'' = shortName of the SwComponentType) == ALIGNMENT == The alignment is used for the Memory Allocation Keywords. {| |- || '''<ALIGNMENT>''' || '''Used for…''' |- || BOOLEAN || variables and constants of size 1 bit |- || 8BIT || variables and constants that have to be aligned to 8 bit. |- || 16BIT || variables and constants that have to be aligned to 16 bit. |- || 32BIT || variables and constants that have to be aligned to 32 bit. |- || UNSPECIFIED || variables, constants, structure, array and unions when SIZE (alignment) does not fit the criteria of 8, 16 or 32 bit. |}   == INIT_POLICY == The initialization policy is used for the Memory Allocation Keywords. <div> {| |- || '''<INIT_POLICY>''' || '''Used for variables that are …''' |- || NO_INIT || never cleared and never initialized. |- || CLEARED ZERO_INIT ⁽¹⁾ || cleared to zero after every reset. |- || POWER_ON_CLEARED || cleared to zero only after power on reset. |- || INIT || initialized with initValue (→5.18) after every reset. |- || POWER_ON_INIT || initialized with initValue (→5.18) only after power on reset. |} ⁽¹⁾ This is actually not specified in the AUTOSAR specifications but often used by different vendors.   == Memory Allocation Keywords == For each Software Component, the declaration and definition of code, variables and constants need to be “wrapped” using the _START_SEC_ and _STOP_SEC_ mechanism: <PREFIX>_'''START'''_SEC_<NAME><MEMORY_ALLOCATION_KEYWORDS> <code>#include <MemMap.h></code> <code> </code> <code>/* Here comes the declaration and definition of code, variables and constants */</code> <code>/* … */</code> <code> </code> <code><PREFIX>_'''STOP'''_SEC_<NAME><MEMORY_ALLOCATION_KEYWORDS></code> <code>#include <MemMap.h></code>   <''PREFIX''> is the shortName of the SwComponentType (case sensitive) <''NAME''> is the shortName of a Software Component Description (case sensitive) if the MemorySection (10.8) has no symbol attribute defined. Otherwise symbol is used for <NAME>. <''MEMORY_ALLOCATION_KEYWORDS''> is used according to Memory Allocation Keywords according to the following table. Example: #define MySwc_'''START_SEC_CODE'''         /* Definition of start symbol for module memory section */ #include "MySwc_MemMap.h"            /* Include of the memory mapping header file */   FUNC(void, MySwc_CODE) Run1( void );  /* Declaration / definition of code, variables or constants                                       belonging to the specified section */ #define MySwc_'''STOP_SEC_CODE'''          /* Definition of stop symbol for module memory section */ #include "MySwc_MemMap.h"            /* Include of the memory mapping header file */   For code which is invariably implemented as inline function the wrapping with Memory Allocation Keywords is not required. <div> {| |- || '''Memory Section Type''' || '''Syntax of Memory Allocation Keyword''' |- || VAR || <PREFIX>_'''START_SEC_VAR'''_<INIT_POLICY>_<ALIGNMENT> <PREFIX>_'''STOP_SEC_VAR'''_<INIT_POLICY>_<ALIGNMENT> all global or static variables. |- || VAR_FAST || <PREFIX>_'''START_SEC_VAR_FAST'''_<INIT_POLICY>_<ALIGNMENT> <PREFIX>_'''STOP_SEC_VAR_FAST'''_<INIT_POLICY>_<ALIGNMENT> Global or static variables that have at least one of the following properties (to save code and runtime): * accessed bitwise * frequently used * high number of accesses in source code |- || VAR_SLOW || <PREFIX>_'''START_SEC_VAR_SLOW'''_<INIT_POLICY>_<ALIGNMENT> <PREFIX>_'''STOP_SEC_VAR_SLOW'''_<INIT_POLICY>_<ALIGNMENT> all infrequently accessed global or static variables. |- || INTERNAL_VAR || <PREFIX>_'''START_SEC_INTERNAL_VAR'''_<INIT_POLICY>_<ALIGNMENT> <PREFIX>_'''STOP_SEC_INTERNAL_VAR'''_<INIT_POLICY>_<ALIGNMENT> global or static variables those are accessible from a calibration tool. |- || VAR_SAVED_ZONE || <PREFIX>_'''START_SEC_VAR_SAVED_ZONE'''<X>_<ALIGNMENT> <PREFIX>_'''STOP_SEC_VAR_SAVED_ZONE'''<X>_<ALIGNMENT> RAM buffers of variables saved in nonvolatile memory. |- || CONST_SAVED_RECOVERY_ZONE || <PREFIX>_'''START_SEC_CONST_SAVED_RECOVERY_ZONE'''<X> <PREFIX>_'''STOP_SEC_CONST_SAVED_RECOVERY_ZONE'''<X> ROM buffers of variables saved in nonvolatile memory. |- || CONST || <PREFIX>_'''START_SEC_CONST'''_<ALIGNMENT> <PREFIX>_'''STOP_SEC_CONST'''_<ALIGNMENT> global or static constants. |- || CALIB || <PREFIX>_'''START_SEC_CALIB'''_<ALIGNMENT> <PREFIX>_'''STOP_SEC_CALIB'''_<ALIGNMENT> global or static constants. |- || CARTO || <PREFIX>_'''START_SEC_CARTO'''_<ALIGNMENT> <PREFIX>_'''STOP_SEC_CARTO'''_<ALIGNMENT> cartography constants. |- || CONFIG_DATA || <PREFIX>_'''START_SEC_CONFIG_DATA'''_<ALIGNMENT> <PREFIX>_'''STOP_SEC_CONFIG_DATA'''_<ALIGNMENT> configuration constants. |- || CODE || <PREFIX>_'''START_SEC_CODE''' <PREFIX>_'''STOP_SEC_CODE''' mapping code to application block, boot block, external flash etc. |- || CALLOUT_CODE || <PREFIX>_'''START_SEC_CALLOUT_CODE''' <PREFIX>_'''STOP_SEC_CALLOUT_CODE''' mapping callouts of the BSW Modules |- || CODE_FAST || <PREFIX>_'''START_SEC_CODE_FAST'''[_<NUM>] <PREFIX>_'''STOP_SEC_CODE_FAST'''[_<NUM>] code that shall go into fast code memory segments. The optional suffix [_<NUM>] can qualify the expected access commonness, e.g. typical period of code execution. |- || CODE_SLOW || <PREFIX>_'''START_SEC_CODE_SLOW''' <PREFIX>_'''STOP_SEC_CODE_SLOW''' code that shall go into slow code memory segments. |- || CODE_LIB || <PREFIX>_'''START_SEC_CODE_LIB''' <PREFIX>_'''STOP_SEC_CODE_LIB''' For code of library segments for BSW module or Software Component. |} </div> </div> 1d0a1dff74d8470a6c2f2b87af3fc7db7517ae25 0 1199 2079 2017-05-17T16:39:45Z Oliver 1 Redirected page to [[Memory Mapping]] wikitext text/x-wiki #REDIRECT [[Memory Mapping]] ddc9c28d967f420eac71abd6ad354e6fc8a9fe90 0 1200 2080 2017-05-17T16:40:53Z Oliver 1 Redirected page to [[Memory Mapping]] wikitext text/x-wiki #REDIRECT [[Memory Mapping]] ddc9c28d967f420eac71abd6ad354e6fc8a9fe90 0 1201 2081 2017-05-17T16:42:45Z Oliver 1 Redirected page to [[Memory Mapping#Memory Allocation Keywords]] wikitext text/x-wiki #REDIRECT [[Memory Mapping#Memory Allocation Keywords]] ce43a5ad9d6e6cc19c17f0f1612b6e2ab85113e9 0 1202 2082 2017-05-17T16:43:09Z Oliver 1 Redirected page to [[Memory Mapping#Memory Allocation Keywords]] wikitext text/x-wiki #REDIRECT [[Memory Mapping#Memory Allocation Keywords]] ce43a5ad9d6e6cc19c17f0f1612b6e2ab85113e9 0 449 2083 1984 2017-05-22T09:28:07Z Oliver 1 wikitext text/x-wiki for BSW Mode Manager (BswM) see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Complex Device Driver|Complex Device Drivers]] =Services Layer= The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ====Communication Services==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ====Memory Services==== * [[NVRAM Manager]] (NvM) ====System Services==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ====Diagnostic Services==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) =ECU Abstraction Layer= The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ====Communication HW Abstraction==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ====Memory HW Abstraction==== * [[Memory Abstraction Interface]] (MemIf) * [[Flash EEPROM Emulation]] (Fee) * [[EEPROM Abstraction]] (Ea) ====Onboard Device Abstraction==== * [[Watchdog Interface]] (WdgIf) ====I/O HW Abstraction==== * [[IO HW Abstraction]] =Microcontroller Abstraction Layer= The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ====Communication Drivers==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ====I/O Drivers==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ====Memory Drivers==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ====Microcontroller Drivers==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) ==Table of Basic Software Modules== (based on AUTOSAR R4.2.2) {| border="1" |+  |- || '''Module Name''' || '''Ma / Msn''' || '''Mod. ID''' || '''Mod. ID''' |- || [[ADC Driver]] || Adc || 123 || 0x7B |- || [[BSW Mode Manager]] || BswM || 42 || 0x2A |- || [[BSW Scheduler Module]] || SchM || 130 || 0x82 |- || [[CAN Driver]] || Can || 80 || 0x50 |- || [[CAN Interface]] || CanIf || 60 || 0x3C |- || [[CAN Network Management]] || CanNm || 31 || 0x1F |- || [[CAN State Manager]] || CanSM || 140 || 0x8C |- || [[CAN Transceiver Driver]] || CanTrcv || 70 || 0x46 |- || [[CAN Transport Layer]] || CanTp || 35 || 0x23 |- || [[COM]] || Com || 50 || 0x32 |- || [[COM Based Transformer]] || ComXf || 175 || 0xAF |- || [[COM Manager]] || ComM || 12 || 0x0C |- || [[Complex Drivers]] || n/a || 255 || 0xFF |- || [[Core Test]] || CorTst || 103 || 0x67 |- || [[Crypto Service Manager]] || Csm || 110 || 0x6E |- || [[Debugging]] || Dbg || 57 || 0x39 |- || [[Default Error Tracer]] || Det || 15 || 0x0F |- || [[Diagnostic Communication Manager]] || Dcm || 53 || 0x35 |- || [[Diagnostic Event Manager]] || Dem || 54 || 0x36 |- || [[Diagnostic Log and Trace]] || Dlt || 55 || 0x37 |- || [[Diagnostic over IP]] || DoIP || 173 || 0xAD |- || [[DIO Driver]] || Dio || 120 || 0x78 |- || [[E2E Transformer]] || E2EXf || 176 || 0xB0 |- || [[ECU State Manager]] || EcuM || 10 || 0x0A |- || [[EEPROM Abstraction]] || Ea || 40 || 0x23 |- || [[EEPROM Driver]] || Eep || 90 || 0x5A |- || [[Ethernet Driver]] || Eth || 88 || 0x58 |- || [[Ethernet Interface]] || EthIf || 65 || 0x41 |- || [[Ethernet State Manager]] || EthSM || 143 || 0x8F |- || [[Ethernet Switch Driver]] || EthSwt || 89 || 0x59 |- || [[Ethernet Transceiver Driver]] || EthTrcv || 73 || 0x49 |- || [[Flash Driver]] || Fls || 92 || 0x5C |- || [[Flash EEPROM Emulation]] || Fee || 21 || 0x15 |- || [[Flash Test]] || FlsTst || 104 || 0x68 |- || [[FlexRay AUTOSAR Transport Layer]] || FrArTp || 38 || 0x26 |- || [[FlexRay Driver]] || Fr || 81 || 0x51 |- || [[FlexRay Interface]] || FrIf || 61 || 0x3D |- || [[FlexRay ISO Transport Layer]] || FrTp || 36 || 0x24 |- || [[FlexRay Network Management]] || FrNm || 32 || 0x20 |- || [[FlexRay State Manager]] || FrSM || 142 || 0x8E |- || [[FlexRay Transceiver Driver]] || FrTrcv || 71 || 0x47 |- || [[Function Inhibition Manager]] || FiM || 11 || 0x0B |- || [[GPT Driver]] || Gpt || 100 || 0x64 |- || [[ICU Driver]] || Icu || 122 || 0x7A |- || [[IO HW Abstraction]] || n/a || 254 || 0xFE |- || [[IPDU Multiplexer]] || IpduM || 52 || 0x34 |- || [[Large Data COM]] || LdCom || 49 || 0x31 |- || [[LIN Driver]] || Lin || 82 || 0x52 |- || [[LIN Interface]] || LinIf || 62 || 0x3E |- || [[LIN Network Management]] || LinNm || 63 || 0x3F |- || [[LIN State Manager]] || LinSM || 141 || 0x8D |- || [[LIN Transceiver Driver]] || LinTrcv || 64 || 0x40 |- || [[MCU Driver]] || Mcu || 101 || 0x65 |- || [[Memory Abstraction Interface]] || MemIf || 22 || 0x16 |- || [[Network Management Interface]] || Nm || 29 || 0x1D |- || [[NVRAM Manager]] || NvM || 20 || 0x14 |- || [[OCU Driver]] || Ocu || 125 || 0x7D |- || [[OS]] || Os || 1 || 0x01 |- || [[PDU Router]] || PduR || 51 || 0x33 |- || [[Port Driver]] || Port || 124 || 0x7C |- || [[PWM Driver]] || Pwm || 121 || 0x79 |- || [[RAM Test]] || RamTst || 93 || 0x5D |- || [[RTE]] || Rte || 2 || 0x02 |- || [[SAE J1939 Diagnostic Communication Manager]] || J1939Dcm || 58 || 0x3A |- || [[SAE J1939 Network Management]] || J1939Nm || 34 || 0x22 |- || [[SAE J1939 Request Manager]] || J1939Rm || 59 || 0x3B |- || [[SAE J1939 Transport Layer]] || J1939Tp || 37 || 0x25 |- || [[Secure Onboard Communication]] || SecOC || 150 || 0x96 |- || [[Service Discovery]] || Sd || 171 || 0xAB |- || [[Socket Adaptor]] || SoAd || 56 || 0x38 |- || [[SOME/IP Transformer]] || SomeIpXf || 174 || 0xAE |- || [[Spi Driver | SPI Handler / Driver]] || Spi || 83 || 0x53 |- || [[Synchronized Time-Base Manager]] || StbM || 160 || 0xA0 |- || [[TCP/IP Stack]] || TcpIp || 170 || 0xAA |- || [[Time Service]] || Tm || 14 || 0x0E |- || [[Time Sync Over CAN]] || CanTSyn || 161 || 0xA1 |- || [[Time Sync Over Ethernet]] || EthTSyn || 164 || 0xA4 |- || [[Time Sync Over FlexRay]] || FrTSyn || 163 || 0xA3 |- || [[TTCAN Driver]] || Ttcan || 84 || 0x54 |- || [[TTCAN Interface]] || TtcanIf || 66 || 0x42 |- || [[UDP Network Management]] || UdpNm || 33 || 0x21 |- || [[Watchdog Driver]] || Wdg || 102 || 0x66 |- || [[Watchdog Interface]] || WdgIf || 43 || 0x2B |- || [[Watchdog Manager]] || WdgM || 13 || 0x0D |- || [[XCP]] || Xcp || 212 || 0xD4 |- || || || || |- || [[CRC Library]] || Crc || 201 || 0xC9 |- || [[BFx Library]] || Bfx || 205 || 0xCD |- || [[Crypto Abstraction Library]] || Cal || 206 || 0xCE |- || [[E2E Library]] || E2E || 207 || 0xCF |- || [[EFx Library]] || Efx || 208 || 0xD0 |- || [[IFl Library]] || Ifl || 209 || 0xD1 |- || [[MFl Library]] || Mfl || 210 || 0xD2 |- || [[MFx Library]] || Mfx || 211 || 0xD3 |- || [[IFx Library]] || Ifx || 213 || 0xD5 |} [[Category:AUTOSAR]] [[Category:Software]] 8da399e5dca224cb842cca179efcfa8ffa6d6a9c 0 449 2084 2083 2017-05-22T13:56:53Z Oliver 1 wikitext text/x-wiki for BSW Mode Manager (BswM) see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Complex Device Driver|Complex Device Drivers]] =Services Layer= The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ====Communication Services==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ====Memory Services==== * [[NVRAM Manager]] (NvM) ====System Services==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ====Diagnostic Services==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) =ECU Abstraction Layer= The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ====Communication HW Abstraction==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ====Memory HW Abstraction==== * [[Memory Abstraction Interface]] (MemIf) * [[Flash EEPROM Emulation]] (Fee) * [[EEPROM Abstraction]] (Ea) ====Onboard Device Abstraction==== * [[Watchdog Interface]] (WdgIf) ====I/O HW Abstraction==== * [[IO HW Abstraction]] =Microcontroller Abstraction Layer= The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ====Communication Drivers==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ====I/O Drivers==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ====Memory Drivers==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ====Microcontroller Drivers==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) ==Table of Basic Software Modules== (based on AUTOSAR R4.2.2) {| border="1" |+  |- || '''Module Name''' || '''Ma / Msn''' || '''Mod. ID''' || '''Mod. ID''' |- || [[ADC Driver]] || [[Adc]] || 123 || 0x7B |- || [[BSW Mode Manager]] || [[BswM]] || 42 || 0x2A |- || [[BSW Scheduler Module]] || [[SchM]] || 130 || 0x82 |- || [[CAN Driver]] || [[Can]] || 80 || 0x50 |- || [[CAN Interface]] || [[CanIf]] || 60 || 0x3C |- || [[CAN Network Management]] || [[CanNm]] || 31 || 0x1F |- || [[CAN State Manager]] || [[CanSM]] || 140 || 0x8C |- || [[CAN Transceiver Driver]] || [[CanTrcv]] || 70 || 0x46 |- || [[CAN Transport Layer]] || [[CanTp]] || 35 || 0x23 |- || [[COM]] || [[Com]] || 50 || 0x32 |- || [[COM Based Transformer]] || [[ComXf]] || 175 || 0xAF |- || [[COM Manager]] || [[ComM]] || 12 || 0x0C |- || [[Complex Drivers]] || n/a || 255 || 0xFF |- || [[Core Test]] || [[CorTst]] || 103 || 0x67 |- || [[Crypto Service Manager]] || [[Csm]] || 110 || 0x6E |- || [[Debugging]] || [[Dbg]] || 57 || 0x39 |- || [[Default Error Tracer]] || [[Det]] || 15 || 0x0F |- || [[Diagnostic Communication Manager]] || [[Dcm]] || 53 || 0x35 |- || [[Diagnostic Event Manager]] || [[Dem]] || 54 || 0x36 |- || [[Diagnostic Log and Trace]] || [[Dlt]] || 55 || 0x37 |- || [[Diagnostic over IP]] || [[DoIP]] || 173 || 0xAD |- || [[DIO Driver]] || [[Dio]] || 120 || 0x78 |- || [[E2E Transformer]] || [[E2EXf]] || 176 || 0xB0 |- || [[ECU State Manager]] || [[EcuM]] || 10 || 0x0A |- || [[EEPROM Abstraction]] || [[Ea]] || 40 || 0x23 |- || [[EEPROM Driver]] || [[Eep]] || 90 || 0x5A |- || [[Ethernet Driver]] || [[Eth]] || 88 || 0x58 |- || [[Ethernet Interface]] || [[EthIf]] || 65 || 0x41 |- || [[Ethernet State Manager]] || [[EthSM]] || 143 || 0x8F |- || [[Ethernet Switch Driver]] || [[EthSwt]] || 89 || 0x59 |- || [[Ethernet Transceiver Driver]] || [[EthTrcv]] || 73 || 0x49 |- || [[Flash Driver]] || [[Fls]] || 92 || 0x5C |- || [[Flash EEPROM Emulation]] || [[Fee]] || 21 || 0x15 |- || [[Flash Test]] || [[FlsTst]] || 104 || 0x68 |- || [[FlexRay AUTOSAR Transport Layer]] || [[FrArTp]] || 38 || 0x26 |- || [[FlexRay Driver]] || [[Fr]] || 81 || 0x51 |- || [[FlexRay Interface]] || [[FrIf]] || 61 || 0x3D |- || [[FlexRay ISO Transport Layer]] || [[FrTp]] || 36 || 0x24 |- || [[FlexRay Network Management]] || [[FrNm]] || 32 || 0x20 |- || [[FlexRay State Manager]] || [[FrSM]] || 142 || 0x8E |- || [[FlexRay Transceiver Driver]] || [[FrTrcv]] || 71 || 0x47 |- || [[Function Inhibition Manager]] || [[FiM]] || 11 || 0x0B |- || [[GPT Driver]] || [[Gpt]] || 100 || 0x64 |- || [[ICU Driver]] || [[Icu]] || 122 || 0x7A |- || [[IO HW Abstraction]] || n/a || 254 || 0xFE |- || [[IPDU Multiplexer]] || [[IpduM]] || 52 || 0x34 |- || [[Large Data COM]] || [[LdCom]] || 49 || 0x31 |- || [[LIN Driver]] || [[Lin]] || 82 || 0x52 |- || [[LIN Interface]] || [[LinIf]] || 62 || 0x3E |- || [[LIN Network Management]] || [[LinNm]] || 63 || 0x3F |- || [[LIN State Manager]] || [[LinSM]] || 141 || 0x8D |- || [[LIN Transceiver Driver]] || [[LinTrcv]] || 64 || 0x40 |- || [[MCU Driver]] || [[Mcu]] || 101 || 0x65 |- || [[Memory Abstraction Interface]] || [[MemIf]] || 22 || 0x16 |- || [[Network Management Interface]] || [[Nm]] || 29 || 0x1D |- || [[NVRAM Manager]] || [[NvM]] || 20 || 0x14 |- || [[OCU Driver]] || [[Ocu]] || 125 || 0x7D |- || [[OS]] || [[Os]] || 1 || 0x01 |- || [[PDU Router]] || [[PduR]] || 51 || 0x33 |- || [[Port Driver]] || [[Port]] || 124 || 0x7C |- || [[PWM Driver]] || [[Pwm]] || 121 || 0x79 |- || [[RAM Test]] || [[RamTst]] || 93 || 0x5D |- || [[RTE]] || [[Rte]] || 2 || 0x02 |- || [[SAE J1939 Diagnostic Communication Manager]] || [[J1939Dcm]] || 58 || [[0x3A]] |- || [[SAE J1939 Network Management]] || [[J1939Nm]] || 34 || 0x22 |- || [[SAE J1939 Request Manager]] || [[J1939Rm]] || 59 || 0x3B |- || [[SAE J1939 Transport Layer]] || [[J1939Tp]] || 37 || 0x25 |- || [[Secure Onboard Communication]] || [[SecOC]] || 150 || 0x96 |- || [[Service Discovery]] || [[Sd]] || 171 || 0xAB |- || [[Socket Adaptor]] || [[SoAd]] || 56 || 0x38 |- || [[SOME/IP Transformer]] || [[SomeIpXf]] || 174 || 0xAE |- || [[Spi Driver | SPI Handler / Driver]] || [[Spi]] || 83 || 0x53 |- || [[Synchronized Time-Base Manager]] || [[StbM]] || 160 || 0xA0 |- || [[TCP/IP Stack]] || [[TcpIp]] || 170 || 0xAA |- || [[Time Service]] || [[Tm]] || 14 || 0x0E |- || [[Time Sync Over CAN]] || [[CanTSyn]] || 161 || 0xA1 |- || [[Time Sync Over Ethernet]] || [[EthTSyn]] || 164 || 0xA4 |- || [[Time Sync Over FlexRay]] || [[FrTSyn]] || 163 || 0xA3 |- || [[TTCAN Driver]] || [[Ttcan]] || 84 || 0x54 |- || [[TTCAN Interface]] || [[TtcanIf]] || 66 || 0x42 |- || [[UDP Network Management]] || [[UdpNm]] || 33 || 0x21 |- || [[Watchdog Driver]] || [[Wdg]] || 102 || 0x66 |- || [[Watchdog Interface]] || [[WdgIf]] || 43 || 0x2B |- || [[Watchdog Manager]] || [[WdgM]] || 13 || 0x0D |- || [[XCP]] || [[Xcp]] || 212 || 0xD4 |- || || || || |- || [[CRC Library]] || [[Crc]] || 201 || 0xC9 |- || [[BFx Library]] || [[Bfx]] || 205 || 0xCD |- || [[Crypto Abstraction Library]] || [[Cal]] || 206 || 0xCE |- || [[E2E Library]] || [[E2E]] || 207 || 0xCF |- || [[EFx Library]] || [[Efx]] || 208 || 0xD0 |- || [[IFl Library]] || [[Ifl]] || 209 || 0xD1 |- || [[MFl Library]] || [[Mfl]] || 210 || 0xD2 |- || [[MFx Library]] || [[Mfx]] || 211 || 0xD3 |- || [[IFx Library]] || [[Ifx]] || 213 || 0xD5 |} [[Category:AUTOSAR]] [[Category:Software]] 274360b75a4ac4ab24239c428642444cd89bd09b 2094 2084 2017-05-22T14:03:23Z Oliver 1 /* Table of Basic Software Modules */ wikitext text/x-wiki for BSW Mode Manager (BswM) see [[BSW Mode Manager|here]] The Basic Software (BSW) consists of Basic Software Modules (BSWM) as a collection of software files (code and description) that define a certain basic software functionality present on an [[ECU]]. [[Standard software]] may be composed of several [[software module]]s that are developed independently. A software module may consist of [[Integration Code]], and/or standard software. Vertically the Basic Software can be grouped into five 'columns': * System * Memory * Communication * Input/Output (I/O) * [[Complex Device Driver|Complex Device Drivers]] =Services Layer= The Services Layer is the highest layer of the [[Basic Software]] which also applies for its relevance for the [[application software]]: while access to I/O signals is covered by the [[Microcontroller Abstraction Layer]], the Services Layer offers * Operating system services * Vehicle network communication and management services * Memory services ([[NVRAM]] management) * Diagnosic Services (including [[KWP2000]] interface and error memory) * [[ECU]] state management * Logical and temporal program flow monitoring ([[WdgM]]) The Services Layer consists of the following parts: ====Communication Services==== * [[CAN Network Management]] (CanNm) * [[CAN State Manager]] (CanSM) * [[CAN Transport Layer]] (CanTp) * [[COM]] (Com) * [[Ethernet State Manager]] (EthSM) * [[FlexRay AUTOSAR Transport Layer]] (FrArTp) * [[FlexRay ISO Transport Layer]] (FrTp) * [[FlexRay Network Management]] (FrNm) * [[FlexRay State Manager]] (FrSM) * [[IPDU Multiplexer]] (IpduM) * [[LIN Network Management]] (LinNm) * [[LIN State Manager]] (LinSM) * [[Network Management Interface]] (Nm) * [[PDU Router]] (PduR) * [[SAE J1939 Transport Layer]] (J1939Tp) * [[Socket Adaptor]] (SoAd) * [[UDP Network Management]] (UdpNm) * [[XCP]] (Xcp) * [[Debugging]] (Dbg) * [[Diagnostic Communication Manager]] (Dcm) ====Memory Services==== * [[NVRAM Manager]] (NvM) ====System Services==== * [[COM Manager]] (ComM) * [[BSW Mode Manager]] (BswM) * [[Crypto Service Manager]] (Csm) * [[ECU State Manager]] (EcuM) * [[Synchronized Time-Base Manager]] (StbM) * [[Watchdog Manager]] (WdgM) * [[OS]] ====Diagnostic Services==== (as part of System Services) * [[Diagnostic Log and Trace]] (DLT) * [[Development Error Tracer]] (Det) * [[Diagnostic Event Manager]] (Dem) * [[Function Inhibition Manager]] (FiM) =ECU Abstraction Layer= The ECU Abstraction Layer is located above the [[Microcontroller Abstraction Layer]] (MCAL) and abstracts from the [[ECU]] schematic. It is implemented for a specific ECU (therefore hardware dependent) and offers an [[API]] for access to peripherals and devices regardless of their location (onchip/offchip) and their connection to the microcontroller (port pins, type of interface) to make higher software layers independent of the ECU hardware layout. The ECU Abstraction Layer consists of the following parts: ====Communication HW Abstraction==== * [[CAN Interface]] (CanIf) * [[CAN Tranceiver Driver]] (CanTrcv) * [[Ethernet Interface]] (EthIf) * [[Ethernet Transceiver Driver]] (EthTrcv) * [[FlexRay Interface]] (FrIf) * [[FlexRay Tranceiver Driver]] (FrTrcv) * [[LIN Interface]] (LinIf) * [[LIN Transceiver Driver]] (LinTrcv) * [[TTCAN Interface]] (TtcanIf) ====Memory HW Abstraction==== * [[Memory Abstraction Interface]] (MemIf) * [[Flash EEPROM Emulation]] (Fee) * [[EEPROM Abstraction]] (Ea) ====Onboard Device Abstraction==== * [[Watchdog Interface]] (WdgIf) ====I/O HW Abstraction==== * [[IO HW Abstraction]] =Microcontroller Abstraction Layer= The Microcontroller Abstraction Layer (MCAL) is the lowest software layer of the [[Basic Software]]. It is [[uC]] dependent and contains [[driver]]s to enable the access of on-chip peripheral devices of a [[microcontroller]] and off-chip memory mapped peripheral devices by a defined [[API]]. The purpose is to make higher software layers independent of the microcontroller. The Microcontroller Abstraction Layer consists of the following parts: ====Communication Drivers==== * [[CAN Driver]] (Can) * [[Ethernet Driver]] (Eth) * [[FlexRay Driver]] (Fr) * [[LIN Driver]] (Lin) * [[TTCAN Driver]] (Ttcan) * [[SPI Handler Driver]] (Spi) ====I/O Drivers==== * [[ADC Driver]] (Adc) * [[DIO Driver]] (Dio) * [[ICU Driver]] (Icu) * [[PWM Driver]] (Pwm) * [[Port Driver]] (Port) ====Memory Drivers==== * [[EEPROM Driver]] (Eep) * [[Flash Driver]] (Fls) * [[RAM Test]] (RamTst) * [[Flash Test]] (FlsTst) ====Microcontroller Drivers==== * [[Core Test]] (CoreTst) * [[GPT Driver]] (Gpt) * [[MCU Driver]] (Mcu) * [[Watchdog Driver]] (Wdg) ==Table of Basic Software Modules== (based on AUTOSAR R4.2.2) {| border="1" |+  |- || '''Module Name''' || '''Ma / Msn''' || '''Mod. ID''' || '''Mod. ID''' |- || [[ADC Driver]] || [[Adc]] || 123 || 0x7B |- || [[BSW Mode Manager]] || [[BswM]] || 42 || 0x2A |- || [[BSW Scheduler Module]] || [[SchM]] || 130 || 0x82 |- || [[CAN Driver]] || [[Can]] || 80 || 0x50 |- || [[CAN Interface]] || [[CanIf]] || 60 || 0x3C |- || [[CAN Network Management]] || [[CanNm]] || 31 || 0x1F |- || [[CAN State Manager]] || [[CanSM]] || 140 || 0x8C |- || [[CAN Transceiver Driver]] || [[CanTrcv]] || 70 || 0x46 |- || [[CAN Transport Layer]] || [[CanTp]] || 35 || 0x23 |- || [[COM]] || [[Com]] || 50 || 0x32 |- || [[COM Based Transformer]] || [[ComXf]] || 175 || 0xAF |- || [[COM Manager]] || [[ComM]] || 12 || 0x0C |- || [[Complex Driver]] || n/a || 255 || 0xFF |- || [[Core Test]] || [[CorTst]] || 103 || 0x67 |- || [[Crypto Service Manager]] || [[Csm]] || 110 || 0x6E |- || [[Debugging]] || [[Dbg]] || 57 || 0x39 |- || [[Default Error Tracer]] || [[Det]] || 15 || 0x0F |- || [[Diagnostic Communication Manager]] || [[Dcm]] || 53 || 0x35 |- || [[Diagnostic Event Manager]] || [[Dem]] || 54 || 0x36 |- || [[Diagnostic Log and Trace]] || [[Dlt]] || 55 || 0x37 |- || [[Diagnostic over IP]] || [[DoIP]] || 173 || 0xAD |- || [[DIO Driver]] || [[Dio]] || 120 || 0x78 |- || [[E2E Transformer]] || [[E2EXf]] || 176 || 0xB0 |- || [[ECU State Manager]] || [[EcuM]] || 10 || 0x0A |- || [[EEPROM Abstraction]] || [[Ea]] || 40 || 0x23 |- || [[EEPROM Driver]] || [[Eep]] || 90 || 0x5A |- || [[Ethernet Driver]] || [[Eth]] || 88 || 0x58 |- || [[Ethernet Interface]] || [[EthIf]] || 65 || 0x41 |- || [[Ethernet State Manager]] || [[EthSM]] || 143 || 0x8F |- || [[Ethernet Switch Driver]] || [[EthSwt]] || 89 || 0x59 |- || [[Ethernet Transceiver Driver]] || [[EthTrcv]] || 73 || 0x49 |- || [[Flash Driver]] || [[Fls]] || 92 || 0x5C |- || [[Flash EEPROM Emulation]] || [[Fee]] || 21 || 0x15 |- || [[Flash Test]] || [[FlsTst]] || 104 || 0x68 |- || [[FlexRay AUTOSAR Transport Layer]] || [[FrArTp]] || 38 || 0x26 |- || [[FlexRay Driver]] || [[Fr]] || 81 || 0x51 |- || [[FlexRay Interface]] || [[FrIf]] || 61 || 0x3D |- || [[FlexRay ISO Transport Layer]] || [[FrTp]] || 36 || 0x24 |- || [[FlexRay Network Management]] || [[FrNm]] || 32 || 0x20 |- || [[FlexRay State Manager]] || [[FrSM]] || 142 || 0x8E |- || [[FlexRay Transceiver Driver]] || [[FrTrcv]] || 71 || 0x47 |- || [[Function Inhibition Manager]] || [[FiM]] || 11 || 0x0B |- || [[GPT Driver]] || [[Gpt]] || 100 || 0x64 |- || [[ICU Driver]] || [[Icu]] || 122 || 0x7A |- || [[IO HW Abstraction]] || n/a || 254 || 0xFE |- || [[IPDU Multiplexer]] || [[IpduM]] || 52 || 0x34 |- || [[Large Data COM]] || [[LdCom]] || 49 || 0x31 |- || [[LIN Driver]] || [[Lin]] || 82 || 0x52 |- || [[LIN Interface]] || [[LinIf]] || 62 || 0x3E |- || [[LIN Network Management]] || [[LinNm]] || 63 || 0x3F |- || [[LIN State Manager]] || [[LinSM]] || 141 || 0x8D |- || [[LIN Transceiver Driver]] || [[LinTrcv]] || 64 || 0x40 |- || [[MCU Driver]] || [[Mcu]] || 101 || 0x65 |- || [[Memory Abstraction Interface]] || [[MemIf]] || 22 || 0x16 |- || [[Network Management Interface]] || [[Nm]] || 29 || 0x1D |- || [[NVRAM Manager]] || [[NvM]] || 20 || 0x14 |- || [[OCU Driver]] || [[Ocu]] || 125 || 0x7D |- || [[OS]] || [[Os]] || 1 || 0x01 |- || [[PDU Router]] || [[PduR]] || 51 || 0x33 |- || [[Port Driver]] || [[Port]] || 124 || 0x7C |- || [[PWM Driver]] || [[Pwm]] || 121 || 0x79 |- || [[RAM Test]] || [[RamTst]] || 93 || 0x5D |- || [[RTE]] || [[Rte]] || 2 || 0x02 |- || [[SAE J1939 Diagnostic Communication Manager]] || [[J1939Dcm]] || 58 || [[0x3A]] |- || [[SAE J1939 Network Management]] || [[J1939Nm]] || 34 || 0x22 |- || [[SAE J1939 Request Manager]] || [[J1939Rm]] || 59 || 0x3B |- || [[SAE J1939 Transport Layer]] || [[J1939Tp]] || 37 || 0x25 |- || [[Secure Onboard Communication]] || [[SecOC]] || 150 || 0x96 |- || [[Service Discovery]] || [[Sd]] || 171 || 0xAB |- || [[Socket Adaptor]] || [[SoAd]] || 56 || 0x38 |- || [[SOME/IP Transformer]] || [[SomeIpXf]] || 174 || 0xAE |- || [[Spi Driver | SPI Handler / Driver]] || [[Spi]] || 83 || 0x53 |- || [[Synchronized Time-Base Manager]] || [[StbM]] || 160 || 0xA0 |- || [[TCP/IP Stack]] || [[TcpIp]] || 170 || 0xAA |- || [[Time Service]] || [[Tm]] || 14 || 0x0E |- || [[Time Sync Over CAN]] || [[CanTSyn]] || 161 || 0xA1 |- || [[Time Sync Over Ethernet]] || [[EthTSyn]] || 164 || 0xA4 |- || [[Time Sync Over FlexRay]] || [[FrTSyn]] || 163 || 0xA3 |- || [[TTCAN Driver]] || [[Ttcan]] || 84 || 0x54 |- || [[TTCAN Interface]] || [[TtcanIf]] || 66 || 0x42 |- || [[UDP Network Management]] || [[UdpNm]] || 33 || 0x21 |- || [[Watchdog Driver]] || [[Wdg]] || 102 || 0x66 |- || [[Watchdog Interface]] || [[WdgIf]] || 43 || 0x2B |- || [[Watchdog Manager]] || [[WdgM]] || 13 || 0x0D |- || [[XCP]] || [[Xcp]] || 212 || 0xD4 |- || || || || |- || [[CRC Library]] || [[Crc]] || 201 || 0xC9 |- || [[BFx Library]] || [[Bfx]] || 205 || 0xCD |- || [[Crypto Abstraction Library]] || [[Cal]] || 206 || 0xCE |- || [[E2E Library]] || [[E2E]] || 207 || 0xCF |- || [[EFx Library]] || [[Efx]] || 208 || 0xD0 |- || [[IFl Library]] || [[Ifl]] || 209 || 0xD1 |- || [[MFl Library]] || [[Mfl]] || 210 || 0xD2 |- || [[MFx Library]] || [[Mfx]] || 211 || 0xD3 |- || [[IFx Library]] || [[Ifx]] || 213 || 0xD5 |} [[Category:AUTOSAR]] [[Category:Software]] 9237448f8ec2d322b167e8c176d5461730ad5005 0 1203 2085 2017-05-22T13:57:34Z Oliver 1 Redirected page to [[ADC Driver]] wikitext text/x-wiki #REDIRECT [[ADC Driver]] e7154a5f8315ba933a6c4064c28a6fb890cb8f8d 0 1204 2086 2017-05-22T13:58:19Z Oliver 1 Redirected page to [[BSW Mode Manager]] wikitext text/x-wiki #REDIRECT [[BSW Mode Manager]] 8f9723449b191f5a8d00cea200467ba52ec48147 0 1205 2087 2017-05-22T13:59:04Z Oliver 1 Redirected page to [[BSW Scheduler Module]] wikitext text/x-wiki #REDIRECT [[BSW Scheduler Module]] 0fa9503cc1205f4106a745af665c6ab2aeac2ef3 0 1206 2088 2017-05-22T13:59:21Z Oliver 1 Redirected page to [[CAN Driver]] wikitext text/x-wiki #REDIRECT [[CAN Driver]] 15bb84c00c085823aae7afb554db1cf3974cea9e 0 1207 2089 2017-05-22T14:01:10Z Oliver 1 Created page with "[[Category:AUTOSAR]] The CAN Tranceiver Driver (CanTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. ===[[AUTOSAR Interface]]=== ===Standardiz..." wikitext text/x-wiki [[Category:AUTOSAR]] The CAN Tranceiver Driver (CanTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. ===[[AUTOSAR Interface]]=== ===[[Standardized AUTOSAR Interface]]=== ===[[Standardized Interface]]=== 61ae8b9e5680283f4a91e7e28b79f101cabfbd9e 0 515 2090 1387 2017-05-22T14:01:29Z Oliver 1 Redirected page to [[CAN Transceiver Driver]] wikitext text/x-wiki #REDIRECT [[CAN Transceiver Driver]] 8b51fbddb9dc8b3aaa2078469b2f7c92a0b75571 0 1208 2091 2017-05-22T14:02:00Z Oliver 1 Redirected page to [[COM]] wikitext text/x-wiki #REDIRECT [[COM]] 30e1b41e92e25ca31dd1003a8d6f48132c316c40 0 1209 2092 2017-05-22T14:02:21Z Oliver 1 Redirected page to [[COM Based Transformer]] wikitext text/x-wiki #REDIRECT [[COM Based Transformer]] cd7e6163efde4b80595dcba0c5aed011b9e23148 0 1210 2093 2017-05-22T14:02:44Z Oliver 1 Redirected page to [[Core Test]] wikitext text/x-wiki #REDIRECT [[Core Test]] 2108e31934d01b960287546dbf8b082aa47d085a 0 1211 2095 2017-05-22T14:04:17Z Oliver 1 Redirected page to [[Debugging]] wikitext text/x-wiki #REDIRECT [[Debugging]] ab02a79bfa135a3b462ef506a00fd14ed6c137d8 0 1212 2096 2017-05-22T14:04:33Z Oliver 1 Redirected page to [[Default Error Tracer]] wikitext text/x-wiki #REDIRECT [[Default Error Tracer]] b4669e6074af99801c7b6e30dd872ec259867f70 0 1213 2097 2017-05-22T14:05:00Z Oliver 1 Redirected page to [[Diagnostic Log and Trace]] wikitext text/x-wiki #REDIRECT [[Diagnostic Log and Trace]] a58b7e28a27c741f4194462617fd579dcb7ba093 0 1214 2098 2017-05-22T14:05:36Z Oliver 1 Redirected page to [[DIO Driver]] wikitext text/x-wiki #REDIRECT [[DIO Driver]] 1a806a2d3f18b7411a36fa16d5e0c2807804ba1a 0 1215 2099 2017-05-22T14:05:52Z Oliver 1 Redirected page to [[E2E Transformer]] wikitext text/x-wiki #REDIRECT [[E2E Transformer]] b38587546eb435cde3a6d0f048a61397a1413618 0 1216 2100 2017-05-22T14:06:15Z Oliver 1 Redirected page to [[EPROM Abstraction]] wikitext text/x-wiki #REDIRECT [[EPROM Abstraction]] f73b54f329be9cfe6d14db376c7c2a846c96cb91 0 1217 2101 2017-05-22T14:06:45Z Oliver 1 Redirected page to [[Ethernet Switch Driver]] wikitext text/x-wiki #REDIRECT [[Ethernet Switch Driver]] 8e2fda1cec9de6d181dcf7898c65b35fab098232 0 1218 2102 2017-05-22T14:07:07Z Oliver 1 Redirected page to [[Flash EEPROM Emulation]] wikitext text/x-wiki #REDIRECT [[Flash EEPROM Emulation]] 1e3e2ffc7ebd6e545c31c819551645ed58849e8a 0 1219 2103 2017-05-22T14:07:33Z Oliver 1 Redirected page to [[FlexRay Driver]] wikitext text/x-wiki #REDIRECT [[FlexRay Driver]] 131b76da53940bf4dd3b0eba063c8456b49c176d 0 474 2104 628 2017-05-22T14:08:16Z Oliver 1 Redirected page to [[FlexRay Transceiver Driver]] wikitext text/x-wiki #REDIRECT [[FlexRay Transceiver Driver]] b171c195a3ba4e6f9c28b5f00f12924295aa8453 0 519 2105 1577 2017-05-22T14:09:13Z Oliver 1 Redirected page to [[FlexRay Transceiver Driver]] wikitext text/x-wiki #REDIRECT [[FlexRay Transceiver Driver]] b171c195a3ba4e6f9c28b5f00f12924295aa8453 0 1220 2106 2017-05-22T14:09:23Z Oliver 1 Created page with "The [[wikipedia:FlexRay|FlexRay]] [[Transceiver]] Driver (FrTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. ===[[AUTOSAR Interface]]=== ===S..." wikitext text/x-wiki The [[wikipedia:FlexRay|FlexRay]] [[Transceiver]] Driver (FrTrcv) is a [[Basic Software Module]] of the [[Communication HW Abstraction]]. ===[[AUTOSAR Interface]]=== ===[[Standardized AUTOSAR Interface]]=== ===[[Standardized Interface]]=== [[Category:AUTOSAR]] 34121850de91eaefbd3f5ea7f176df91619012c5 0 1221 2107 2017-05-22T14:09:39Z Oliver 1 Redirected page to [[Function Inhibition Manager]] wikitext text/x-wiki #REDIRECT [[Function Inhibition Manager]] 3c352fbc1594758a2d2eedf84a2d0de4586d9fdb 0 1222 2108 2017-05-22T14:09:57Z Oliver 1 Redirected page to [[GPT Driver]] wikitext text/x-wiki #REDIRECT [[GPT Driver]] b181c0c5b9ecae26d236d427b618128385de643a 0 1223 2109 2017-05-22T14:10:10Z Oliver 1 Redirected page to [[ICU Driver]] wikitext text/x-wiki #REDIRECT [[ICU Driver]] 5f239f7f542317fc88fbda449438a43f9c96cef1 0 1224 2110 2017-05-22T14:10:29Z Oliver 1 Redirected page to [[Large Data COM]] wikitext text/x-wiki #REDIRECT [[Large Data COM]] 8679d0e656a875358d5025933214eced4c76014d 0 1225 2111 2017-05-22T14:10:46Z Oliver 1 Redirected page to [[LIN Driver]] wikitext text/x-wiki #REDIRECT [[LIN Driver]] 6afc66ab05270899555bb1c8dc90cc22dbdd4255 0 1226 2112 2017-05-22T14:11:11Z Oliver 1 Redirected page to [[MCU Driver]] wikitext text/x-wiki #REDIRECT [[MCU Driver]] d098c7b32dd6b0f5f5a1dd03fc8e5b48d8a96149 0 1227 2113 2017-05-22T14:11:28Z Oliver 1 Redirected page to [[NVRAM Manager]] wikitext text/x-wiki #REDIRECT [[NVRAM Manager]] 8bc3aff50363bded8d5b8738cf201a82549c61c2 0 1228 2114 2017-05-22T14:11:46Z Oliver 1 Redirected page to [[OCU Driver]] wikitext text/x-wiki #REDIRECT [[OCU Driver]] 7c7f852d4760adc54c152f76bd54f45a09412050 0 1229 2115 2017-05-22T14:12:07Z Oliver 1 Redirected page to [[OS]] wikitext text/x-wiki #REDIRECT [[OS]] 6c828ee59ed9aadb96710da1bd5809eb6142d358 0 1230 2116 2017-05-22T14:12:27Z Oliver 1 Redirected page to [[PWM Driver]] wikitext text/x-wiki #REDIRECT [[PWM Driver]] 9685b8a7ac8e198670358488e2daa0c7478d635d 0 1231 2117 2017-05-22T14:12:46Z Oliver 1 Redirected page to [[RTE]] wikitext text/x-wiki #REDIRECT [[RTE]] d225abd574f37226704f9e2fe0138846b2a46010 0 1232 2118 2017-05-22T14:13:03Z Oliver 1 Redirected page to [[SAE J1939 Diagnostic Communication Manager]] wikitext text/x-wiki #REDIRECT [[SAE J1939 Diagnostic Communication Manager]] eb3c329d9ef9486f2de945379537d08d78c5cfc7 0 1233 2119 2017-05-22T14:13:16Z Oliver 1 Redirected page to [[SAE J1939 Network Management]] wikitext text/x-wiki #REDIRECT [[SAE J1939 Network Management]] 3ab647e6dffaac13e3a870a10618567cf8a9b1eb 0 1234 2120 2017-05-22T14:13:30Z Oliver 1 Redirected page to [[SAE J1939 Request Manager]] wikitext text/x-wiki #REDIRECT [[SAE J1939 Request Manager]] ad446bfaa3ce737b06a9b16b4c4dd3375b85c699 0 1235 2121 2017-05-22T14:13:45Z Oliver 1 Redirected page to [[Secure Onboard Communication]] wikitext text/x-wiki #REDIRECT [[Secure Onboard Communication]] f9bdaf0bbb1f08636fb099b2603b056b19dc8430 0 1236 2122 2017-05-22T14:14:00Z Oliver 1 Redirected page to [[Service Discovery]] wikitext text/x-wiki #REDIRECT [[Service Discovery]] 754c8d15723ec38e89ae6b55827f28535c2ff743 0 1237 2123 2017-05-22T14:14:20Z Oliver 1 Redirected page to [[SOME/IP Transformer]] wikitext text/x-wiki #REDIRECT [[SOME/IP Transformer]] cfdac328c5ab7865eaf6b26c34f719bbc2d73b01 0 1238 2124 2017-05-22T14:15:02Z Oliver 1 Redirected page to [[SPI Handler Driver]] wikitext text/x-wiki #REDIRECT [[SPI Handler Driver]] fafe91bc7e05f6faade445649d6ae527180e7814 0 1239 2125 2017-05-22T14:15:22Z Oliver 1 Redirected page to [[TCP/IP Stack]] wikitext text/x-wiki #REDIRECT [[TCP/IP Stack]] 7bacef6b05cef7794b26a6d52d4f9055237314fd 0 1240 2126 2017-05-22T14:15:37Z Oliver 1 Redirected page to [[Time Service]] wikitext text/x-wiki #REDIRECT [[Time Service]] d2cb0580751f6c3ab198d4924e4f710af23f2049 0 1241 2127 2017-05-22T14:15:50Z Oliver 1 Redirected page to [[Time Sync Over CAN]] wikitext text/x-wiki #REDIRECT [[Time Sync Over CAN]] 0d7b17b2f274c2442e72bae0c9ca17379a9d2019 0 1242 2128 2017-05-22T14:16:05Z Oliver 1 Redirected page to [[Time Sync Over Ethernet]] wikitext text/x-wiki #REDIRECT [[Time Sync Over Ethernet]] 01e9c6307f52827590d00d0633d0c8af307779b6 0 1243 2129 2017-05-22T14:16:19Z Oliver 1 Redirected page to [[Time Sync Over FlexRay]] wikitext text/x-wiki #REDIRECT [[Time Sync Over FlexRay]] 8973cfd08a1e9313d441f7b76518c0ca5cd03bba 0 1244 2130 2017-05-22T14:16:35Z Oliver 1 Redirected page to [[TTCAN Driver]] wikitext text/x-wiki #REDIRECT [[TTCAN Driver]] 2fcfe14387a2621188d735e81454fc57a72903bf 0 1245 2131 2017-05-22T14:17:22Z Oliver 1 Redirected page to [[CRC Library]] wikitext text/x-wiki #REDIRECT [[CRC Library]] be02c32364e55582baddbfb23fb5fabc72633f1c 0 1246 2132 2017-05-22T14:17:43Z Oliver 1 Redirected page to [[BFx Library]] wikitext text/x-wiki #REDIRECT [[BFx Library]] 960e6364287fd21d06aa7bc724d926811e14ef2a 0 1247 2133 2017-05-22T14:18:04Z Oliver 1 Redirected page to [[Crypto Abstraction Library]] wikitext text/x-wiki #REDIRECT [[Crypto Abstraction Library]] 8ae90cc98a727cbc6bbd47dd4e2b013d0b61d4f6 0 1248 2134 2017-05-22T14:18:27Z Oliver 1 Redirected page to [[EFx Library]] wikitext text/x-wiki #REDIRECT [[EFx Library]] 97d8478ac1233ac19a80ec2d92723acae3d54291 0 363 2135 427 2017-05-22T14:18:42Z Oliver 1 Redirected page to [[E2E Library]] wikitext text/x-wiki #REDIRECT [[E2E Library]] a829fd269f590e77a5905ad1b3f2ee14cd00e737 0 1249 2136 2017-05-22T14:18:59Z Oliver 1 Redirected page to [[IFl Library]] wikitext text/x-wiki #REDIRECT [[IFl Library]] b51373c19effcd97a959c99ca0fb1f8fc49b6a1f 0 1250 2137 2017-05-22T14:19:15Z Oliver 1 Redirected page to [[MFl Library]] wikitext text/x-wiki #REDIRECT [[MFl Library]] 534b055d844fda15e8f555fbaf51e47f523dbf54 0 1251 2138 2017-05-22T14:19:28Z Oliver 1 Redirected page to [[MFx Library]] wikitext text/x-wiki #REDIRECT [[MFx Library]] 8177e211e1638ccebcd6c63fa9ea2ce9341a2b8b 0 1252 2139 2017-05-22T14:19:43Z Oliver 1 Redirected page to [[IFx Library]] wikitext text/x-wiki #REDIRECT [[IFx Library]] 9fc65fcc5009579309d37665bc07fd56a9b3a2bc 0 1253 2140 2017-05-23T08:35:31Z Oliver 1 Redirected page to [[Vehicle Identification number]] wikitext text/x-wiki #REDIRECT [[Vehicle Identification number]] 15b5f103e8ded8f55a269b2c6ebf7b070880e7ac 0 159 2141 2061 2017-05-23T08:49:06Z Oliver 1 wikitext text/x-wiki [[Category:AUTOSAR]] [[Category:software]] [[Category:hardware]] In the [[AUTOSAR]] sense an Electronic Control Unit (ECU) means a microcontroller plus peripherals with corresponding software. For software configuration each microcontroller requires its own [[ECU Configuration]]. There are many different ECUs working inside a vehicle as the following list of examples shows: {| class="wikitable" |- ||'''Abbr.''' ||'''Full name''' ||'''German full name''' |- ||ABS ||Anti-Lock Brake System ||Anti Blockiersystem |- ||ACC || Adaptive Cruise Control ||Abstandsregel-Tempomat |- ||AFS || Active Front Steering<br />Advanced Frontlighting System || |- ||BCM || Body Control Module<br />Brake Control Module || |- ||BJB ||Battery Junction Box || |- ||BMS ||Battery Management System || |- ||CCM ||Climate Control Module ||Klima-Steuergerät |- ||CMC ||Cell Module Controller || |- ||ECM ||Engine Control Module || |- ||EPAS ||Electronic Power Assisted Steering || |- ||ESC, ESP ||Electronic Stability Control (Program) ||Elektronisches Stabilitätsprogramm |- ||(E)SCL ||(Electronic) Steering Column Lock ||ELV = Elektronische Lenkverriegelung |- ||EMS ||Engine Management System ||Motormanagement |- ||ESS ||Energy Storage System || |- ||HU ||Head Unit || |- ||SBC ||Sensoric Brake Control ||Elektrohydraulisches Bremssystem |- ||IPC ||Instrument Panel Cluster || |- ||LSM ||Light Switch Module || |- ||PAM ||Park Assist Module ||Parkassistent |- ||PDC ||Park Distance Control || |- ||RSM ||Rain Sensor Module || |- ||TBM ||Trailer Brake Module || |- ||TRM ||Trailer Module || |- ||TCS ||Traction Control System || |- || || || |} ECUs might also be grouped into * Powertrain * Chassis * Body * Multi Media * etc. cb28205d344d326b3b27aa277e8a2a4dad0e3c93 0 1254 2142 2017-05-23T10:12:53Z Oliver 1 Redirected page to [[Development Interface Agreement]] wikitext text/x-wiki #REDIRECT [[Development Interface Agreement]] 52e3547e30361d7364b952fe435408cd9e3239bf 0 1255 2143 2017-05-23T10:58:39Z Oliver 1 Redirected page to [[Electronic Control Unit]] wikitext text/x-wiki #REDIRECT [[Electronic Control Unit]] 36e857917fdce8ea1b3a7e8262deb830a9919664 0 1185 2144 2065 2017-05-23T13:35:40Z Oliver 1 Redirected page to [[Fault Tolerant Time Interval]] wikitext text/x-wiki #REDIRECT [[Fault Tolerant Time Interval]] 0bb8447fed797219b24b5e413332548dabbbd20a 0 1256 2145 2017-05-23T13:36:01Z Oliver 1 Redirected page to [[Fault Tolerant Time]] wikitext text/x-wiki #REDIRECT [[Fault Tolerant Time]] 53b19a8931122054ac262ec462d57ebe0f2d3ffe 0 1257 2146 2017-05-23T13:36:45Z Oliver 1 Redirected page to [[Fault Tolerant Time Interval]] wikitext text/x-wiki #REDIRECT [[Fault Tolerant Time Interval]] 0bb8447fed797219b24b5e413332548dabbbd20a 0 1259 2148 2017-05-31T09:09:56Z Oliver 1 Created page with "For "little endian" start with the least significant byte first – the significance of the byte increases with the increasing byte significance. (little end first) see also [..." wikitext text/x-wiki For "little endian" start with the least significant byte first – the significance of the byte increases with the increasing byte significance. (little end first) see also [[Big endian]] [[Category:Software]] c907b3890240ccab5bf6773b2ec55ad844a00efb 2153 2148 2017-05-31T09:19:39Z Oliver 1 Redirected page to [[Endianness]] wikitext text/x-wiki #REDIRECT [[Endianness|Little endian]] 0559850ff62fbce499f0a16e9ce83fc69e193a52 0 1260 2149 2017-05-31T09:10:11Z Oliver 1 Created page with "For "big endian" start with the most significant byte first - the significance of the byte decreases with the increasing byte significance. (big end first)<br /> see also Li..." wikitext text/x-wiki For "big endian" start with the most significant byte first - the significance of the byte decreases with the increasing byte significance. (big end first)<br /> see also [[Little endian]] [[Category:Software]] 676d8d732fd3ff1cece1397c0302c5aad3795541 2152 2149 2017-05-31T09:19:08Z Oliver 1 Redirected page to [[Endianness]] wikitext text/x-wiki #REDIRECT [[Endianness|Big endian]] 91a54aa55df4eaf0aa0893d33856223983ca5174 0 1261 2150 2017-05-31T09:17:11Z Oliver 1 Created page with "AUTOSAR has two categories of data types: “normal” ones, which [[Endianness]] can be converted, and “'''opaque'''”, for which COM does not do any conversions. Categ..." wikitext text/x-wiki AUTOSAR has two categories of data types: “normal” ones, which [[Endianness]] can be converted, and “'''opaque'''”, for which COM does not do any conversions. [[Category:AUTOSAR]] [[Category:Software]] 87e3befa4301abdad364c34a2e9107083bd3a640 0 1262 2151 2017-05-31T09:18:51Z Oliver 1 Created page with "==Little endian== For "little endian" start with the least significant byte first – the significance of the byte increases with the increasing byte significance. (little end..." wikitext text/x-wiki ==Little endian== For "little endian" start with the least significant byte first – the significance of the byte increases with the increasing byte significance. (little end first) ==Big endian== For "big endian" start with the most significant byte first - the significance of the byte decreases with the increasing byte significance. (big end first) [[Category:Software]] 2557859a681f39abb03e3e0d052e51629b319e3b 0 1263 2154 2017-05-31T16:25:29Z Oliver 1 Created page with "Development Interface Agreement is a document that defines interfaces and documents between customer and supplier.It is required for safey related systems according to wikip..." wikitext text/x-wiki Development Interface Agreement is a document that defines interfaces and documents between customer and supplier.It is required for safey related systems according to [[wikipedia:ISO 26262|ISO 26262]]: # the appointment of the customer’s and the supplier’s safety managers, # the joint tailoring of the safety lifecycle in accordance with ISO 26262-2:2011, 6.4.5, # the activities and processes to be performed by the customer and the activities and processes to be performed by the supplier, # the information and the work products to be exchanged,<br />NOTE 1 This includes an agreement on the documentation to be provided for the completion of the customer's and supplier's safety cases. <br />NOTE 2 The information exchanged includes the safety-related special characteristics.<br />NOTE 3 In the case of a distributed development, the relevant parts of the work products necessary for the activities of the development parties involved can be identified and exchanged. # the parties or persons responsible for the activities, # the communication of the target values, derived from the system level targets, to each relevant party in order for them to meet the target values for single-point faults metric and latent faults metric in accordance with the evaluation of the hardware architectural metrics and the evaluation of safety goal violations due to random hardware failures (see ISO 26262-5), and # the supporting processes and tools, including interfaces, to assure compatibility between customer and supplier. [[Category:Safety]] b4b9a687c62cfac4302bba5bcc656178aa585129 0 1264 2155 2017-06-02T09:37:44Z Oliver 1 Redirected page to [[Safety Element out of Context]] wikitext text/x-wiki #REDIRECT [[Safety Element out of Context]] f3961cf7f2e763918f0b0516f4c493373673a52c 0 1265 2156 2017-06-02T09:38:36Z Oliver 1 Created page with "A Safety Element out of context (SEooC) is a safety-related element which is not developed for a specific item. This means it is not developed in the context of a particular s..." wikitext text/x-wiki A Safety Element out of context (SEooC) is a safety-related element which is not developed for a specific item. This means it is not developed in the context of a particular system or vehicle. [[Category:Safety]] f0f5c50b1d8540ef189adc47b80ff3846b6305cb 2157 2156 2017-06-02T09:42:15Z Oliver 1 wikitext text/x-wiki A Safety Element out of context (SEooC) is a safety-related element which is not developed for a specific item. This means it is not developed in the context of a particular system or vehicle.<br />See [[wikipedia:ISO 26262|ISO 26262]] Part 10 "Guideline on ISO 26262", Chapter 9 "Safety element out of context" [[Category:Safety]] 03261ed15fb4c30cd3d3ce70c8469fea82bfcc01 0 1266 2158 2017-06-14T10:32:15Z Oliver 1 Redirected page to [[wikipedia:Multiple Independent Levels of Security]] wikitext text/x-wiki #REDIRECT [[wikipedia:Multiple Independent Levels of Security|Multiple Independent Levels of Security]] 3db4184526dbf47ed4704c7a69e39fdb3b5ddc6e 0 1164 2159 2035 2017-07-04T15:01:43Z Oliver 1 /* Services */ added 0x2A wikitext text/x-wiki =Services= {| class="wikitable" |- !|Service ID (hex) !|Service !|Description |- ||0x10 ||Diagnostic Session Control || |- ||0x11 ||ECU Reset || |- ||0x14 ||Clear Diagnostic Information || |- ||0x19 ||Read DTC Information || |- ||0x22 ||Read Data By Identifier || |- ||0x23 ||Read Memory By Address || |- ||0x27 ||Security Access || |- ||0x28 ||Communication Control || |- ||0x2A ||Read Data by Periodic ID || |- ||0x2E ||Write Data By Identifier || |- ||0x2F ||Input Output Control By Identifier || |- ||0x31 ||Routine Control || |- ||0x34 ||Request Download || |- ||0x35 ||Request Upload || |- ||0x36 ||Transfer Data || |- ||0x37 ||Transfer Exit || |- ||0x3D ||Write Memory By Address || |- ||0x3E ||Tester Present || |- ||0x85 ||Control DTC Setting || |} =Negative response codes= The negative response codes (NRC) are divided into 3 ranges: * 0x00: positiveResponse parameter value for server internal implementation, * 0x01 – 0x7F: communication related negative response codes, * 0x80 – 0xFF: negative response codes for specific conditions that are not correct at the point in time the request is received by the server. These response codes may be utilized whenever response code 0x22 (conditionsNotCorrect) is listed as valid in order to report more specifically why the requested action can not be taken. {| class="wikitable" |- !|value !|responseCode !|Description |- ||0x00 ||positiveResponse ||This response code shall not be used in a negative response message. This positiveResponse parameter value is reserved for server internal implementation. |- ||0x01 - 0x0F ||ISOSAEReserved ||This range of values is reserved by this document for future definition. |- ||0x10 ||generalReject ||This response code indicates that the requested action has been rejected by the server. The generalReject response code shall only be implemented in the server if none of the negative response codes defined in this document meet the needs of the implementation. At no means shall this response code be a general replacement for other response codes defined. |- ||0x11 ||serviceNotSupported ||This response code indicates that the requested action will not be taken because the server does not support the requested service. The server shall send this response code in case the client has sent a request message with a service identifier, which is either unknown or not supported by the server. Therefore this negative response code is not shown in the list of negative response codes to be supported for a diagnostic service, because this negative response code is not applicable for supported services. |- ||0x12 ||subFunctionNotSupported ||This response code indicates that the requested action will not be taken because the server does not support the service specific parameters of the request message. The server shall send this response code in case the client has sent a request message with a known and supported service identifier but with "sub function“ which is either unknown or not supported. |- ||0x13 ||incorrectMessageLengthOrInvalidFormat ||This response code indicates that the requested action will not be taken because the length of the received request message does not match the prescribed length for the specified service or the format of the parameters do not match the prescribed format for the specified service. |- ||0x14 ||responseTooLong ||This response code shall be reported by the server if the response to be generated exceeds the maximum number of bytes available by the underlying network layer. |- ||0x15 - 0x20 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x21 ||busyRepeatReques ||This response code indicates that the server is temporarily too busy to perform the requested operation. In this circumstance the client shall perform repetition of the "identical request message" or "another request message". The repetition of the request shall be delayed by a time specified in the respective implementation documents. Example: In a multi-client environment the diagnostic request of one client might be blocked temporarily by a NRC $21 while a different client finishes a diagnostic task.NOTE If the server is able to perform the diagnostic task but needs additional time to finish the task and prepare the response, the NRC 0x78 shall be used instead of NRC 0x21.This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- ||0x22 ||conditionsNotCorrect ||This response code indicates that the requested action will not be taken because the server prerequisite conditions are not met. |- ||0x23 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x24 ||requestSequenceError ||This response code indicates that the requested action will not be taken because the server expects a different sequence of request messages or message as sent by the client. This may occur when sequence sensitive requests are issued in the wrong order. EXAMPLE A successful SecurityAccess service specifies a sequence of requestSeed and sendKey as sub-functions in the request messages. If the sequence is sent different by the client the server shall send a negative response message with the negative response code 0x24 (requestSequenceError). |- ||0x25 - 0x30 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x31 ||requestOutOfRange ||This response code indicates that the requested action will not be taken because the server has detected that the request message contains a parameter which attempts to substitute a value beyond its range of authority (e.g. attempting to substitute a data byte of 111 when the data is only defined to 100), or which attempts to access a dataIdentifier/routineIdentifer that is not supported or not supported in active session. This response code shall be implemented for all services, which allow the client to read data, write data or adjust functions by data in the server. |- ||0x32 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x33 ||securityAccessDenied ||This response code indicates that the requested action will not be taken because the server's security strategy has not been satisfied by the client. The server shall send this response code if one of the following cases occur: * the test conditions of the server are not met, * the required message sequence e.g. DiagnosticSessionControl, securityAccess is not met, * the client has sent a request message which requires an unlocked server. <br />Beside the mandatory use of this negative response code as specified in the applicable services within this standard, this negative response code can also be used for any case where security is required and is not yet granted to perform the required service. |- ||0x34 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x35 ||invalidKey ||This response code indicates that the server has not given security access because the key sent by the client did not match with the key in the server's memory. This counts as an attempt to gain security. The server shall remain locked and increment its internal securityAccessFailed counter. |- ||0x36 ||exceedNumberOfAttempts ||This response code indicates that the requested action will not be taken because the client has unsuccessfully attempted to gain security access more times than the server's security strategy will allow. |- ||0x37 ||requiredTimeDelayNotExpired ||This response code indicates that the requested action will not be taken because the client's latest attempt to gain security access was initiated before the server's required timeout period had elapsed. |- ||0x38 - 0x4F ||reservedByExtendedDataLinkSecurityDocument ||This range of values is reserved by ISO 15764 Extended data link security. |- ||0x50 - 0x6F ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x70 ||uploadDownloadNotAccepted ||This response code indicates that an attempt to upload/download to a server's memory cannot be accomplished due to some fault conditions. |- ||0x71 ||transferDataSuspended ||This response code indicates that a data transfer operation was halted due to some fault. The active transferData sequence shall be aborted. |- ||0x72 ||generalProgrammingFailure ||This response code indicates that the server detected an error when erasing or programming a memory location in the permanent memory device (e.g. Flash Memory). |- ||0x73 ||wrongBlockSequenceCounter ||This response code indicates that the server detected an error in the sequence of blockSequenceCounter values. Note that the repetition of a TransferData request message with a blockSequenceCounter equal to the one included in the previous TransferData request message shall be accepted by the server. |- ||0x74 - 0x77 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x78 ||requestCorrectlyReceived-ResponsePending ||This response code indicates that the request message was received correctly, and that all parameters in the request message were valid, but the action to be performed is not yet completed and the server is not yet ready to receive another request. As soon as the requested service has been completed, the server shall send a positive response message or negative response message with a response code different from this. The negative response message with this response code may be repeated by the server until the requested service is completed and the final response message is sent. This response code might impact the application layer timing parameter values. The detailed specification shall be included in the data link specific implementation document. This response code shall only be used in a negative response message if the server will not be able to receive further request messages from the client while completing the requested diagnostic service. When this response code is used, the server shall always send a final response (positive or negative) independent of the suppressPosRspMsgIndicationBit value. A typical example where this response code may be used is when the client has sent a request message, which includes data to be programmed or erased in flash memory of the server. If the programming/erasing routine (usually executed out of RAM) is not able to support serial communication while writing to the flash memory the server shall send a negative response message with this response code. This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- ||0x79 - 0x7D ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x7E ||subFunctionNotSupportedInActiveSession ||This response code indicates that the requested action will not be taken because the server does not support the requested sub-function in the session currently active. Within the programmingSession negative response code 0x12 (subFunctionNotSupported) may optionally be reported instead of negative response code 0x7F (subFunctionNotSupportedInActiveSession). This response code shall only be used when the requested sub-function is known to be supported in another session, otherwise response code 0x12 (subFunctionNotSupported) shall be used. This response code shall be supported by each diagnostic service with a sub-function parameter, if not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- ||0x7F ||serviceNotSupportedInActiveSession ||This response code indicates that the requested action will not be taken because the server does not support the requested service in the session currently active. This response code shall only be used when the requested service is known to be supported in another session, otherwise response code 0x11 (serviceNotSupported) shall be used. This response code is in general supported by each diagnostic service, as not otherwise stated in the data link specific implementation document, therefore it is not listed in the list of applicable response codes of the diagnostic services. |- ||0x80 ||ISOSAEReserved ||This range of values is reserved for future definition. |- ||0x81 ||rpmTooHigh ||This response code indicates that the requested action will not be taken because the server prerequisite condition for RPM is not met (current RPM is above a pre-programmed maximum threshold). |- ||0x82 ||rpmTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for RPM is not met (current RPM is below a pre-programmed minimum threshold). |- ||0x83 ||engineIsRunning ||This is required for those actuator tests which cannot be actuated while the Engine is running. This is different from RPM too high negative response and needs to be allowed. |- ||0x84 ||engineIsNotRunning ||This is required for those actuator tests which cannot be actuated unless the Engine is running. This is different from RPM too low negative response, and needs to be allowed. |- ||0x85 ||engineRunTimeTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for engine run time is not met (current engine run time is below a preprogrammed limit). |- ||0x86 ||temperatureTooHigh ||This response code indicates that the requested action will not be taken because the server prerequisite condition for temperature is not met (current temperature is above a preprogrammed maximum threshold). |- ||0x87 ||temperatureTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for temperature is not met (current temperature is below a preprogrammed minimum threshold). |- ||0x88 ||vehicleSpeedTooHigh ||This response code indicates that the requested action will not be taken because the server prerequisite condition for vehicle speed is not met (current VS is above a pre-programmed maximum threshold). |- ||0x89 ||vehicleSpeedTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for vehicle speed is not met (current VS is below a pre-programmed minimum threshold). |- ||0x8A ||throttle/PedalTooHigh ||This response code indicates that the requested action will not be taken because the server prerequisite condition for throttle/pedal position is not met (current TP/APP is above a preprogrammed maximum threshold). |- ||0x8B ||throttle/PedalTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for throttle/pedal position is not met (current TP/APP is below a preprogrammed minimum threshold). |- ||0x8C ||transmissionRangeNotInNeutral ||This response code indicates that the requested action will not be taken because the server prerequisite condition for being in neutral is not met (current transmission range is not in neutral). |- ||0x8D ||transmissionRangeNotInGear ||This response code indicates that the requested action will not be taken because the server prerequisite condition for being in gear is not met (current transmission range is not in gear). |- ||0x8E ||ISOSAEReserved ||This range of values is reserved by this document for future definition. |- ||0x8F ||brakeSwitch(es)NotClosed (Brake Pedal not pressed or not applied) ||For safety reasons, this is required for certain tests before it begins, and must be maintained for the entire duration of the test. |- ||0x90 ||shifterLeverNotInPark ||For safety reasons, this is required for certain tests before it begins, and must be maintained for the entire duration of the test. |- ||0x91 ||torqueConverterClutchLocked ||This response code indicates that the requested action will not be taken because the server prerequisite condition for torque converter clutch is not met (current TCC status above a preprogrammed limit or locked). |- ||0x92 ||voltageTooHigh ||This response code indicates that the requested action will not be taken because the server prerequisite condition for voltage at the primary pin of the server (ECU) is not met (current voltage is above a pre-programmed maximum threshold). |- ||0x93 ||voltageTooLow ||This response code indicates that the requested action will not be taken because the server prerequisite condition for voltage at the primary pin of the server (ECU) is not met (current voltage is below a pre-programmed maximum threshold). |- ||0x94 - 0xFE ||reservedForSpecificConditionsNotCorrect ||This range of values is reserved for future definition. |- ||0xFF ||ISOSAEReserved ||This range of values is reserved for future definition. |} =DTC Status Byte= {| class="wikitable" |- !|bit # !|hex !|state !|description |- ||0 ||0x01 ||testFailed ||DTC failed at the time of the request |- ||1 ||0x02 ||testFailedThisOperationCycle ||DTC failed on the current operation cycle |- ||2 ||0x04 ||pendingDTC ||DTC failed on the current or previous operation cycle |- ||3 ||0x08 ||confirmedDTC ||DTC is confirmed at the time of the request |- ||4 ||0x10 ||testNotCompletedSinceLastClear ||DTC test not completed since the last code clear |- ||5 ||0x20 ||testFailedSinceLastClear ||DTC test failed at least once since last code clear |- ||6 ||0x40 ||testNotCompletedThisOperationCycle ||DTC test not completed this operation cycle |- ||7 ||0x80 ||warningIndicatorRequested ||Server is requesting warningIndicator to be active |} 4fcaa214026f5ebb08e5398acdee79ef437d299b